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1.  Introduction 

In  early  2013,  the  Stanford  Center  for  Biomedical  Informatics  Research  (BMIR)  received  a  contract  from  TATRC  to 
develop  a  “Common  Language”  for  clinical  functional  assessment  (CFA-CL).  It  was  a  two-year  contract  starting  in 
February  2013  and  terminating  in  February  2015.  This  document  is  the  final  report  that  summarizes  results  obtained 
in  the  two-year  project.  It  describes  our  findings  on  the  DoD/VA’s  Integrated  Disability  Evaluation  System  (IDES), 
our  revised  project  goals,  our  modeling  approach,  and  the  artifacts  developed  in  the  project.  To  make  this  report  self- 
contained,  when  appropriate,  we  incorporate  the  findings  reported  in  the  annual  report  submitted  at  the  end  of  the 
first  contract  year.  We  submit  as  appendices  two  papers,  one  titled  “Structured  Data  Acquisition  with  Ontology- 
Based  Web  Forms”  and  the  second  titled  “Driving  Structured  Data  Entry  for  Functional  Assessment  Using  Standard 
Terminologies.”  As  of  this  writing,  the  former  paper  has  been  accepted  for  publication  and  presentation  at  the 
International  Conference  on  Biomedical  Ontology  2015  (Lisbon,  Portugal).  The  latter  paper  is  under  review  for 
presentation  at  the  American  Medical  Informatics  Association  2015  Annual  Symposium. 

2.  Keywords 

Functional  Status;  International  Classification  of  Functioning,  Disability,  and  Health;  Disability  Benefit 
Questionnaire;  Integrated  Disability  Evaluation  System 

3.  Overall  Project  Summary 

We  have  named  the  project  “FACSIMILE.”1  Its  initial  goals,  as  described  in  our  original  proposal,  include: 

•  Development  of  a  “Common  Language”  (CFA-CL)  for  clinical  function  assessments  that  is  grounded  in 
International  Classification  of  Functioning,  Disability,  and  Health  (ICF) 

•  Demonstration  that  data  used  in  DoD/VA’s  Integrated  Disability  Evaluation  System  (IDES)  can  be  coded 
in  this  common  language 

•  Demonstration  of  uses  of  coded  clinical  function  assessment  data  in  the  IDES  process 

•  Creation  of  a  prototype  CFA  semantic  model  in  which  categories  of  impairment  are  defined  by  constraint 
expressions  consisting  of  the  CFA-CL  and  ICF  code  stems,  qualifiers,  and  qualifier  values. 

Our  focus  has  been  IDES,  through  which  DoD  and  VA  providers  and  coordinators  both  evaluate  a  service  member 
for  fitness  for  service  and  determine  a  possible  disability  rating  in  parallel,  thus  reducing  the  required  processing 
time  for  a  disabled  service  member  to  begin  receiving  benefits.  In  the  following,  we  describe  the  results  of  the 
project  in  terms  of  the  tasks  outlined  in  the  Statement  of  Work. 

1.  Analyze  the  functional  requirements  of  tasks  in  the  Integrated  Disability  Evaluation 
System  (IDES)  workflow  where  clinical  functions  are  assessed,  documented,  stored, 
transmitted,  and  used. 

In  the  first  part  of  this  project,  we  engaged  in  extensive  consultation  with  colleagues  in  Madigan  Army  Medical 
Center  to  determine  (1)  the  nature  of  clinical  assessment  information  generated  and  used  in  IDES,  and  (2) 
opportunities  to  use  coded  clinical  functional  assessment  information  to  inform  decision-making  in  IDES. 

In  the  IDES  process,  when  the  illness  or  injury  of  a  service  member  fits  the  criteria  defined  in  the  medical 
fitness  standards  for  retention  and  separation  (e.g.,  Army  Regulation  40-501  [2]),  and  further  treatment  will  not 
cause  the  member  to  meet  medical  retention  standards  or  render  them  capable  of  performing  the  duties  required 
by  their  office,  grade,  rank,  and  rating,  the  heath-care  provider  refers  the  service  member  to  a  Medical 
Evaluation  Board  (MEB)  for  the  initiation  of  the  IDES  process  and  a  Physical  Evaluation  Board  Liaison  Officer 
(PEBLO)  is  appointed  for  the  service  member.  The  PEBLO  prepares  and  submits  the  case  file  to  a  VA  Military 
Service  Coordinator  (MSC),  who  initiates  VA  processing  of  the  case,  schedules  a  medical  exam,  and  sends  the 
exam  results  to  the  PEBLO.  The  MEB  providers  use  all  available  information  to  produce  a  narrative  summary. 
The  narrative  summary,  together  with  the  service  member’s  medical  and  service  profiles  and  the  history  and 
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treatment  of  the  injury  or  illness,  is  used  by  the  MEB  to  determine  whether  the  member  has  a  medical  condition 
that  is  incompatible  with  continued  military  service  in  his  or  her  current  capacity.  After  a  review  process,  the 
case  file  is  sent  to  the  Physical  Evaluation  Board  (PEB)  for  determining  the  service  member’s  fitness  for 
service.  An  informal  PEB  makes  the  initial  determination,  and  if  the  service  member  is  found  unfit,  submits  a 
request  for  disability  ratings  of  all  claimed  conditions.  A  Disability  Rating  Activity  Site  issues  a  rating  based  on 
the  findings  of  the  VA  medical  examination.  The  process  ends  when  all  reviews  and  appeals  have  been 
processed  and  the  disposition  of  the  case  is  approved  by  the  Physical  Disability  Agency  (PDA)  for  the  service 
member’s  return  to  duty  or  for  the  issuance  of  a  VA’s  benefits  decision  letter. 

We  found  that  Madigan  AMC’s  IDES  data  processing  relies  on  PDF  documents.  The  documents  include 
narrative  summaries  in  free  text  (Figure  1)  or  form-based  documents  that  are  accessible  as  PDFs  (Figure  2). 
Because  there  is  no  coding  scheme  for  clinical  functional  assessments  (something  that  this  project  aimed  to 
address),  functional  assessment  information  in  Madigan’ s  IDES  documentation  is  scattered  in  various  narrative 
documents.  ICD  codes  are  the  only  structured  data  that  are  readily  available.  We  procured  an  example  of  the 
dossier  that  is  generated  for  a  service  member.  It  consisted  of  45  pages  of  mostly  narrative  notes  that  would 
require  significant  time  to  redact  and  de-identify.  The  dossier  provided  many  examples  of  clinical  functional 
assessments  (e.g.,  see  highlighted  text  in  Figure  1).  However,  it  would  take  herculean  effort  to  convert  such  free 
text  into  coded  data  post  hoc.  Within  the  workflow  of  IDES  as  carried  out  at  Madigan,  we  saw  no  prospect  of 
such  structured  coding  being  done.  We  concluded  that  it  was  unrealistic  to  expect  that  we  could  obtain  a  large 
sample  of  de-identified  data  from  Madigan. 

Furthermore,  it  was  not  clear  what  would  be  a  good  use  case  for  the  structured  functional  assessment 
information  in  Madigan’ s  current  IDES  process.  Madigan  MEB  physicians  and  a  PEB  officer  emphasized  to  us 
in  interviews  that  the  retention  decision  is  based  on  a  holistic  evaluation  of  many  sources  of  information, 
including  the  service  member’s  motivation  and  his/her  superiors’  assessments,  rather  than  on  any  kind  of 
structured  assessment  data.  We  struggled  to  find  decision  points  where  structured  data  could  play  a  role  in 
Madigan’ s  IDES  process. 

Nevertheless,  IDES  is  a  complex  and  evolving  process  where  a  number  of  DoD  and  VA  information  systems 
interact  with  each  other.  We  did  not  rule  out  the  possibility  of  structured  functional  assessment  data  becoming 
useful  in  Madigan’ s  IDES  process  in  the  future. 

SPECIFIC  HISTORY  FOR:  CHRONIC  BILATERAL  HIP  CONDITION  SECONDARY  TO  OSTEOARTHRITIS 

The  claimant  reports  being  diagnosed  with  CHRONIC  BILATERAL  HIP  CONDITION  SECONDARY  TO  OSTEOARTHRITIS'. 

The  condition  has  existed  since  2005.  The  condition  started  after  a  12  mile  road  march  He  reports  the  following  symptom(s):  pain.  He 
indicates  he  does  not  experience  weakness,  stiffness,  swelling,  heat,  redness,  giving  way,  lack  of  endurance,  locking,  fatigability, 
deformity,  tenderness,  drainage,  effusion,  subluxation  and  dislocation.  The  claimant  reports  experiencing  the  following  flare-ups  as 
often  as  7  time(s)  per  week  and  each  time  lasts  for  1  day(s).  From  1  to  10  (10  being  the  worst)  the  severity  level  is  at  10.  The  flare- 
ups  are  occurring  spontaneously.  It  is  alleviated  by  rest,  spontaneously  and  by  Toradol.  During  the  flare-ups  he  experiences  the 
following  functional  impairment  which  is  described  as  not  able  to  run  or  walk  fast  and  limitation  of  motion  of  the  joint  w'hich  is 
described  as  limited  range  of  motion.  He  reports  difficulty  with  standing/walking.  The  claimant  describes  can  t  stand  or  sit  still  for 
more  than  3o  minutes  The  treatment  is  Toradol,  physical  training,  Tylenol 

Figure  1.  Example  of  functional  assessment  information  embedded  in  narrative  text  of  notes. 
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PHYSICAL  PROFILE 

For  use  of  this  form,  see  AR  40-501 ;  the  proponent  agency  is  the  Office  of  the  Surgeon  General. 


1.  MEDICAL  CONDITION:  (Description  in  lay  terminology)  X  |  INJURY?  Or  |  |  ILLNESSvDlSEASE? 

Blisters-  hip  pan  {femoral  acetabular  impingement  left  greater  than  right,  and  osteoarthritis);  obstructive  sleep  apnea  ( 

P2) 

2.  CODES  ( Table 

7-2  AR  40-501) 

B  |  F  | 

3 

Temporary 

Permanent 

P 

U 

L 

H 

E 

s 

2 

1 

3 

1 

1 

1 

4  PROFILE  TYPE 

YES 

NO 

a.  TEMPORARY  PROFILE  (Expiration  dote  YYYVMMODi  {limited  to  3 months  duration) 

II 

jX 

b.  PERMANENT  PROFILE  (Reviewed  and  validated  with  every  periodic  hee«b  assessment  or  after  5  years  from  the  dare  of  issue) 

lx| 

5  FUNCTIONAL  ACTIVITIES  THAT  EVERY  SOLDIER  REGARDLESS  OF  MOS  MUST  BE  ABLE  TO  PERFORM  IF  SOLDIER  CANNOT  PERFORM  ANY  ONE  OF 

THESE  TASKS.  THEN  THE  PULHES  MUST  CONTAIN  AT  LEAST  ONE  "3"  AND  SOLDIER  MUST  BE  REFERRED  TO  A  MEB.  CAN  THE  SOLDIER: 

FUNCTIONAL  ACTIVITY: 

YES 

NO 

a.  Carry  and  fire  individual  assigned  weapon"? 

fX)  ; 

1 

1 

b.  Evade  direct  and  indirect  fire? 

□ 

X 

c.  Ride  in  a  military  vehrcle  for  at  least  12  hours  per  day? 

|x! 

d.  Wear  a  helmet  for  at  least  12  hours  per  day? 

[Xj 

e.  Wear  body  armor  for  at  least  12  hours  per  day? 

X 

f.  Wear  load  bearing  equipment  (LBE)  for  at  least  12  hours  per  day? 

X 

g.  Wear  military  boots  and  uniform  for  at  least  12  hours  per  day? 

h.  Wear  protective  mask  and  MOPP  4  for  at  least  2  continuous  hours  per  day? 

[X 

i.  Move  40Jbs  (for  example,  duffie  bag)  while  wearing  usual  protective  gear  (helmet,  weapon,  body  armor  and  LBE)  at  least  100  yards? 

"I* 

_ 

j.  Live  in  an  austere  environment  without  worsening  the  medical  condition? 

L 

X 

6.  APFT 

YES 

NO 

ALTERNATE  APFT  {Fltf  out  if  unable  to  do  APf7  run  otherwise  N/A) 

N/A 

YES 

NO 

2  MILE  RUN 

n 

|x| 

APFT  WALK 

IT 

APFT  SIT-UPS 

1*1 

APFT  SWIM 

□ 

1* 

APFT  PUSH  UPS 

!*| 

APFT  BIKE 

EL 

7.  DOES  THE  SOLDIER  MEET  RETENTION  STANDARD! 

S  lAWCt 

t  AFTER  3  AR  40-501? 

;  YES  □  NEEDS  MMRB  NO  [x]  NEEDS  MEB 

8.  FUNCTIONAL  LIMITATIONS  AND  CAPABILITIES  AND  OTHER  COMMENTS: 

No  Crawling,  Crouching,  Running,  or  Weiflht  bearing  tor  more  than  20  pounds. 

No  wearing  individual  body  armor.  No  wearing  rucksack.  No  wearing  load-bearing  vest  No  running.  No  impact  activity.  No  Sit-ups.  No  flutter  kicks.  No  walking  greater 


Figure  2.  Example  of  formed  based  information  collection. 


Locally,  we  interviewed  Dr.  Michael  Tierney,  a  physician  at  the  VA  Palo  Alto  Health  Care  System  who 
evaluates  service  members  from  all  branches  of  the  military.  These  interviews  revealed  the  variations  in  the 
IDES  documentation  practices  of  different  service  branches.  In  early  2013,  for  example,  the  Navy  used 
Disability  Benefit  Questionnaires  (DBQs),  which  are  problem-specific  assessment  instruments  whose 
component  questions  are  designed  to  elicit  the  information  needed  to  complete  a  disability  rating  based  on  the 
rating  schedules  of  Code  of  Federal  Regulations  Part  4.  In  early  2013,  the  workflow  in  Army’s  IDES  did  not 
use  DBQs.  However,  according  to  members  of  our  Advisory  Board,  all  branches  subsequently  have  transitioned 
to  the  use  of  DBQs.  The  current  Separation  Health  Assessment  (SHA)  makes  use  of  a  General  Medical  (Gen 
Med)  Examination  DBQ  template,  which  is  intended  to  be  a  brief  clinical  summary  and  which  requires  that  the 
details  of  each  condition  to  be  recorded  in  the  individual  specialty  DBQs. 

In  response  to  these  developments,  we  focused  our  attention  on  DBQs  as  potential  instruments  for  capturing 
structured  functional  assessment  information.  We  developed  semantic  models  of  typical  DBQs,  investigated  the 
nature  of  data  elements  in  DBQs,  developed  CFA-CL  that  models  the  semantics  of  DBQ  data  elements,  and 
showed  how  such  model  can  drive  the  generation  of  forms  to  acquire  such  structured  data  and  how  such  data 
can  be  queried. 

2.  Propose  a  structure  for  CFA-CL.  The  CFA-CL  coding  scheme  will  be  described  in  a 
document  and  also  modeled  as  an  OWL  ontology  using  the  Protege  tool. 

In  our  original  proposal,  we  hypothesized  that  CFA-CL  codes  will  have  the  form  of  NNNN.e.xxxx,  where 
NNNN  is  an  ICF  stem  code  at  either  the  3  or  4  digit  level,  e  is  an  optional  extension  code  that  augments  the  ICF 
code  to  have  greater  specificity  than  that  which  is  available  in  ICF,  and  xxvx  denotes  a  set  of  category-specific 
qualifiers.  For  example,  the  Hip  and  Thigh  Conditions  DBQ  evaluates  the  function  of  the  hip  in  terms  flexion, 
extension,  abduction,  and  rotation.  In  ICF,  the  closest  code  for  these  functions  is  b7100  (functions  of  the  range 
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and  ease  of  movement  of  one  joint).  We  hypothesized  that  the  stem  code  7100  can  be  augmented  by  a  4- value 
extension  code  that  indicates  which  of  the  more  specific  functions  is  being  evaluated.  For  this  extended  stem 
code,  we  used  three  qualifiers:  the  first  indicates  the  specific  joint  that  is  involved  (hip,  in  this  case),  the  second 
indicates  the  laterality,  and  the  third  indicates  severity,  where  the  severity  still  depends  on  the  specific  function 
being  evaluated. 

Our  detailed  investigation  of  DBQ  data  elements  suggested  that  developing  a  specific  coding  scheme  from  the 
outset  was  a  suboptimal  approach.  First,  a  coding  scheme  is  a  syntactic  construct  and  the  optimal  syntax  is  often 
dependent  on  specific  use  cases.  For  example,  DBQs  are  organized  in  terms  of  data  elements  (e.g.,  “deep  tendon 
reflexes  of  right  knee”)  and  data  values  (e.g.,  values  from  a  5-valued  scale).  From  the  point  of  view  of  capturing 
DBQ  data,  it  was  necessary  to  formulate  the  data  as  consisting  of  a  data-element  description  and  an  acquired 
value,  instead  of  coding  it  as  a  stem  code  with  qualifiers.  The  key  is  that,  if  we  had  a  consistent  semantic  model 
of  the  data  elements  and  values,  we  could  serialize  them  in  alternative,  equivalent  syntaxes  and  infer  the 
equivalence  of  data  encoded  in  the  different  syntaxes. 

Similarly,  instead  of  creating  arbitrary  extensions  to  ICF  codes,  we  could  express  the  information  content  of  the 
extensions  more  effectively  as  part  of  a  semantic  model  of  the  data  element.  We  needed  to  distinguish  between 
measurements  of  functions,  where  the  entities  being  measured  are  often  represented  by  external  terminologies, 
and  assessments  that  are  abstractions  conceptually  closer  to  the  notions  that  ICF  codes  are  designed  to 
represent.  Logical  Observation  Identifier  Names  and  Codes  (LOINC),  for  example,  have  many  ready-made 
codes  for  the  measurements  that  are  recorded  in  DBQs  (such  as  extension,  rotation,  and  flexion  of  various 
joints).  DBQ  assessments,  such  as  impairment  of  movement  of  the  back  (thoracolumbar  spine),  can  be  mapped 
to  ICF.  In  both  cases,  detailed  coding  required  that  we  add  additional  qualifiers,  such  as  whether  a  range  of 
motion  is  measured  after  repetition  of  actions.  Such  qualifiers  could  be  added  as  attributes  in  a  semantic  model 
of  the  data  elements. 

Given  the  difficulty  of  obtaining  de-identified  data  for  development  purposes,  and  the  impracticality  of 
abstracting  functional  assessment  information  from  directly  narrative  text,  we  consulted  with  our  Scientific 
Advisory  Board.  We  came  to  the  conclusion  that  the  best  way  forward  would  be  to  focus  not  on  existing 
unstructured  data  and  a  syntactic  coding  scheme  such  as  the  one  in  the  original  project  proposal,  where 
functional  assessment  information  is  represented  by  a  code  stem  and  a  set  of  code-specific  qualifiers,  but  rather 
on  developing  a  framework  for  structuring  and  using  functional  assessment  information  prospectively. 

This  framework  included  ontologies  that  describe  the  semantics  of  functional  and  related  data  elements,  their 
relationships  to  standard  terminologies  and  classifications,  models  of  data-collection  instruments,  and  data 
models  for  structuring  assessed  functional  assessment  information.  We  implemented  the  framework  as  a 
collection  of  ontologies  using  the  Protege  tool.  See  Task  6  for  details  of  how  the  semantic  model  for  functional 
assessment  information  is  structured. 

The  Protege  tool  with  which  we  created  the  ontologies  and  data  models  has  a  feature  to  export  the  content  as  a 
collection  of  inter-related  HTML  pages  (Figure  3).  This  feature  allowed  us  to  integrate  documentation  for  the 
model  as  part  of  the  ontology. 
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Contents 

•  All  Ontologies 

•  Classes  (1642) 

•  Object  Properties  (28) 

•  Data  Properties  (39) 

•  Annotation  Properties  (14) 

•  Individuals  (241) 

•  Datatypes  (5) 

cfa 

•  Classes  (112) 

•  Object  Properties  (28) 

- uu.i  - 

•  cfa  frequently 

•  cfa:ft 

•  cfa :  Function 

•  cfa:FunctionalAssessment 

•  cfa:FunctionalFinding 

•  cfa  :GaitCoordinationAnd  Bala  nee 

•  cfa:great_toe 

•  cfa:GuardingOrMusdeSpasmWOAbnormalG; 

•  cfa:has_contributing_factor 

•  cfa :  has  Address 

•  cfa:hasAnatomicalLocationCode 

•  cfa:hasAssessedFunction 

•  cfa:hasBodyStructure 

•  cfa:hasCategory 

•  cfa:hasCodedValue 

•  cfa:hasComponent 

•  cfa:hasContributingFactor 

•  cfa:hasDataValue 

•  cfa:hasDescription 


Class:  cfa:FunctionalAssessment 

http://purl.org/facsimile/cfa#FunctionalAssessment 
Annotations  (1) 

•  rdfs:comment  "Has  describing  components:  function,  severity,  anat.  location,  assistive  device,  etc."  (xsd:string) 

Superclasses  (1) 

•  cfa:  Assessment 

Disjoints  (35) 

'cfa:Memory,  attention,  concentration,  executive  functions',  cfacarry,  cfa:communication,  cfa: consciousness, 
cfa  judgment,  cfa:left_ankle_dorsiflexion_MS,  cfa:left_ankle_plantar_flexion_MS,  cfa:left_great_toe_extension_MS, 
cfa:left_hip_flexion_MS,  cfa:left_knee_flexion_MS,  cfa: lift,  cfa:lift_carry_frequently,  cfa:lift_carry_occasionally, 
cfa:lift_constantly,  cfa:lift_frequently,  cfa:  lift  Jo  wer,  cfa:lift_occasionally,  cfa:lower, 

cfa:motor_activity_withJntact_motor_and_sensory_system,  cfa:orientation,  cfa:palmar_f!exion,  cfa:pull,  cfa:push, 
cfa :put_down,  cfa: right_ankle_dorsiflexion_MS,  cfa :right_ankle_plantar_flexion_MS, 
cfa:right_great_toe_extension_MS,  cfa:right_hip_flexion_MS,  cfa:right_knee_flexion_MS,  cfa: sit, 
cfa:socialJnteraction,  cfa:stand,  cfa:subjective_symptoms,  cfa:visual_spatial_orientation,  cfa:walk 

Usage  (36) 

•  Class:  cfa:FunctionalAssessment 

•  'cfa:Memory,  attention,  concentration,  executive  functions':  cfa:FunctionalAssessment 

•  cfa:carry:  cfa:FunctionalAssessment 

•  cfa  communication:  cfa:FunctionalAssessment 

•  cfa  consciousness:  cfa:FunctionalAssessment 

•  cfa  judgment:  cfa:FunctionalAssessment 

•  cfa:left_ankle_dorsiflexion_MS:  cfa:FunctionalAssessment 

•  cfa:left_ankle_plantar_flexion_MS:  cfa:FunctionalAssessment 

•  cfa:left_great_toe_extension_MS:  cfa:FunctionalAssessment 

•  cfa:left_hip_flexion_MS:  cfa:FunctionalAssessment 

•  cfa:left_knee_flexion_MS:  cfa:FunctionalAssessment 

•  cfa :  lift:  cfa  functional  Assessment 

•  cfa:lift_carry_frequently:  cfa:FunctionalAssessment 

•  cfa: lift  carry  occasionally:  cfa:FunctionalAssessment 


Figure  3.  HTML  pages  documenting  the  CFA-CL  ontology. 

3.  Using  the  proposed  CFA-CL  structure,  we  will  develop  a  web-based  editing  tool  for 
specifying  CFA-CL  code  stems,  their  qualifiers,  and  value  sets  for  the  qualifiers. 

We  successfully  imported  the  CFA-CL  semantic  model  into  WebProtege,  which  provided  us  with  a  Web-based 
environment  for  editing  the  ontologies,  data  models,  and  service-member  data  (Figure  4). 
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<Qprotege  Project  -  Sh 

WebProtege  Clinical  Functional  Assessment  Common  Language  x  Clinical  Functional  Assessment  Common  Language 
Classes  Properties  Individuals  x  Notes  and  Discussions  Changes  By  Entity  x  Project  Dashboard  x 


Classes  +■  &  $  XI  Named  individual  description  for  judgment 

Create  Delete  V\tetch  Branch  ▼  Search-.  Display  name  |judgmeflt 

3  O  owLThing  http://purl.0rg/facsimile/cfa#judgment 

S  O  Case 
3  O  Criteria 

a  O  CrlteriaExpression  Types  Functional  Assessment 

a  O  Data 

a  DataElementDescription 
|  a  O  Finding 
I  a  ObservableEntity 

!  a  C  Assessment  Properties  isExactMatchOf  P1645.  Judgement 

FunctionalAssessment 
'  ICFMappedFunctionalAssessrr 
a  Measurement 

Observation  ListDescription 

RfilntionalFinriinn  _ 

Individuals  for  ®(Xj 

FunctionalAssessment 

Create  Delete  Search.  |  Type  search  strir 

•  Memory,  attention,  concentration,  executive 
functions 

•  carry 

•  communication 

•  consciousness 
judgment 

left_a  nkle_dorsiflexion_MS 

•  left_ankle_plantar_flexion_MS 

•  left_great_toe_extension_MS 

•  left_hip_flexion_MS 

•  left_knee_flexion_MS 

•  lift 

Figure  4.  A  WebProtege  form  for  displaying  and  editing  the  ’’Judgment”  data  element.  Note  that  this  data  element 
has  an  exact  match  to  the  ICF  domain  bl635. 

4.  We  will  populate  CFA-CL  with  a  selected  subset  of  possible  musculoskeletal  code  stems, 
their  qualifiers,  and  value  sets  for  the  qualifiers. 

We  examined  a  set  of  existing  instruments,  including  DBQs  for  lower  back,  knee  and  lower  leg,  ischemic 
diseases,  and  traumatic  brain  injury;  the  Military  Occupation  Specialties  book;  and  SSA’s  residual  functional 
assessments.2  For  the  reasons  discussed  previously,  we  focused  on  the  semantics  of  the  associated  functional 
entities  and  did  not  experiment  with  a  specific  coding  syntax. 

5.  We  will  create  a  prototype  CFA  semantic  model  in  which  categories  of  impairment  are 
defined  by  constraint  expressions  consisting  of  the  CFA-CL  and  ICF  code  stems, 
qualifiers,  and  qualifier  values. 

In  the  CFA-CL  framework,  patient-specific  functional-assessment  data  would  be  represented  as  semantic 
structures  that  are  derived  automatically  as  part  of  an  enhanced  data-entry  process.  We  examined  a  set  of 
existing  instruments  as  described  in  Task  4  and  modeled  the  structure  and  data  elements  in  these  instruments. 
Assessment  instruments  have  sections  and  questions  whose  answers  may  be  free  text  or  may  come  from  specific 


_ m 

*  4*  c>  X 

It 

* 


2  The  DBQs  are  VBA-21-0960M-14-ARE-Back.pdf,  VBA-21-0960M-9-ARE-KneeLowerLeg.pdf,  VBA-21-0960A- 
1-ARE-ischemic,  NEURO  -  TBI  Initial  DBQ  9-15-1  l.doc. 
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value  sets.  Questions  have  descriptions  of  the  data  being  solicited.  Descriptions  of  questions  and  the  value  sets 
for  their  answers  may  use  domain-specific  terminologies. 

To  illustrate  the  structure  of  the  CFA-CL  Semantic  Model,  we  take  a  question  from  the  DBQ  for  the  lower 
back.  One  of  the  assessments  is  a  measurement  of  the  forward  flexion  of  the  back  (Figure  5): 


SECTION  IV  -  INITIAL  RANGE  OF  MOTION  (ROM)  MEASUREMENTS 

4  MEASURE  ROM  WITH  A  GONIOMETER,  ROUNDING  EACH  MEASUREMENT  TO  THE  NEAREST  5  DEGREES.  DURING  THE  MEASUREMENTS,  OBSERVE  THE  POINT - 

AT  WHICH  PAINFUL  MOTION  BEGINS,  EVIDENCED  BY  VISIBLE  BEHAVIOR  SUCH  AS  FACIAL  EXPRESSION,  WINCING,  ETC.  REPORT  INITIAL  MEASUREMENTS  BELOW. 
NOTE:  Following  the  initial  assessment  of  ROM,  perform  repetitive-use  testing.  For  VA  purposes,  repetitive-use  testing  must  be  included  m  all  exams.  The  VA  has 
determined  that  3  repetitions  of  ROM  (at  minimum)  can  serve  as  a  representative  test  of  the  effect  of  repetitive  use.  After  the  initial  measurement,  reassess  ROM  after 
3  repetitions  Report  post-test  measurements  m  section  5. 

A.  SELECT  WHERE  FORWARD  FLEXION  ENDS  (normal  endpoint  is  90). 

□  o  □  5  Dio  □  15  □  20  □  25  □  30  D35  EUO  D45 

Q  50  Q  55  O  60  Q  65  Q  70  Q  75  Q  80  Q  85  Q  90  or  greater 

Figure  5.  DBQ  Range  of  Motion  Measurement 


We  modeled  the  question  as  having  an  isAbout  property  (i.e.,  the  data  element  description),  text,  and  possible 
values  (Figure  6): 


Description:  DBCLBack_Q4A_l  0000  I  Property  assertions:  DBQ_Back_C  111000 


Types  ^p 

•  hasValue  oooo 

exactly  1  Thing 

#  hasValue  some  o@oo 

({degree_0  , 
degree_10  , 
degree_15  , 
degree_20  , 
degree_25  ( 
degree_30  , 
degree_35  , 
degree_40  , 
degree_45  ,  degre 
,  degree_50  , 
degree_55  , 
degree_60  , 
degree_65  , 
degree_70  , 
degree_75  , 
degree_80  , 
degree_85  , 
degree_90plus>) 


>  Question 


Object  property  assertions 

m  isAbout  A@00 

trunk_flexion_initial 

Data  property  assertions 

■  hasText  "SELECT  o@oo 

WHERE  FORWARD 
FLEXION  ENDS 
(normal  endpoint  is 
90)"AAstring 


Negative  object  property  assertions  ^p 
Negative  data  property  assertions  ^p 


Figure  6.  Modeling  of  Range  of  Motion  data  element. 
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The  semantic  model  of  the  initial  trunk- flexion  data  element  was  described  in  terms  a  number  of  properties 
(Figure  7): 


Description:  cfa:trunk  flexion  initial  HB00  ■  Property  assertions:  cfa:trunk  flexion  initial 


•  cfa:RangeOfMotionMeasurem 
ent 


Same  Individual  As  4 


Different  Individuals  \ 


Object  property  assertions 

■  cfa : motion OfROMMeasu rement  'cfa  :flexion 
(forward  flexion)' 

■  cfa  :hasAnatomicalLocationCode 
cfa:lumbar-thoracic_spine 

m  cfa  :contextOfROMMeasu rement  cfa  initial 

■  cf  a :  m  ea  su  redOrAssessedAtt  ri  bu  te 
cfa:angle_at_end 


Figure  7.  Semantic  model  for  the  trunk-flexion  data  element. 


By  associating  the  structured  representation  with  components  of  an  assessment  instrument  administered 
electronically,  the  acquired  data  could  be  converted  as  instances  of  the  CFA-CL  Semantic  Model  automatically, 
obviating  the  need  to  have  human  reviewers  extracting  and  coding  the  data.  A  structured  datum  representing  an 
initial  trunk  flexion  measurement  would  look  like  an  EHR  datum  (e.g.,  an  Observation  in  the  Health  Level  7 
Reference  Information  Model).  At  the  minimum,  it  would  have  a  reference  to  the  focus  of  observation  (e.g., 
trunk  flexion  initial),  a  value  (e.g.,  80  degrees),  and  the  ID  of  the  patient. 

Our  analysis  of  the  data  elements  in  assessment  instruments  suggested  that  multiple  terminologies  were  needed 
to  formalize  the  data-element  descriptions.  DBQs  explicitly  require  the  use  of  ICD  for  coding  diagnoses.  Many 
signs  and  symptoms  are  concepts  better  coded  in  standard  clinical  terminologies  such  as  SNOMED  CT.  Among 
functional  assessments,  a  significant  subset  involves  detailed  measurements  such  as  assessments  of  the  range  of 
motion  in  specific  joints.  ICF,  with  its  relatively  high-level  functional  categories,  is  not  designed  for  recording 
such  measurements.  We  determined  that,  among  standard  clinical  terminologies,  LOINC  has  the  appropriate 
codes  for  such  measurements.  For  example,  LOINC  41343-5  represents  quantitative  measurement  of  the  angle 
of  left-knee  flexion.  Currently,  ICF  is  one  of  four  standard  terminologies  to  which  we  map  descriptions  of 
assessment-data  elements.  The  mappings  may  be  refined  to  specify  that  the  data  element  description  is  an  exact 
match,  a  specialization,  or  a  generalization  of  the  terminology  concept. 

6.  We  will  define  mappings  between  a  selected  subset  of  CFA-CL  terms  and  ICF  terms 
such  that  the  mappings  allow  us  to  programmatically  translate  CFA-CL— coded  data 
into  corresponding  ICF-coded  data. 

We  modeled  CFA-CL-coded  data  as  instances  of  a  class  called  datamodel: Observation  (Figure  8).  We 
investigated  two  alternative  methods  to  relate  such  data,  encoded  in  CFA-CL,  to  ICF.  The  first  method, 
described  here,  translates  the  CFA-CL-coded  data  into  ICF-coded  data  format,  using  Semantic  Web  Rule 
Language  (SWRL)  rules  and  a  collection  of  mapping  specifications  encoded  in  the  Web  Ontology  Language 
(OWL).  The  second  method,  described  in  Task  12,  defined  functional  assessment  data  elements  in  terms  of  ICF 
concepts,  making  the  resulting  data  queryable  in  terms  of  ICF  concepts  without  converting  the  data  into  ICF- 
coded  format. 

Use  of  SWRL  rules  to  translate  CFA-CL-coded  data  to  ICF-coded  data 

For  ICF-coded  data,  we  create  a  model  consisting  of  classes  that  corresponded  to  each  of  the  four  ICF  axes: 
Body  Structure,  Body  Function,  Activities  and  Participation,  and  Environmental  Factor.  For  each  class,  we 
specified  the  allowed  qualifiers.  Figure  9  shows  the  data  model  for  “Body  Structure”  data.  It  specifies  that  an 
ICF-coded  datum  for  body-structure  impairment  must  include  the  nature,  extent,  and  location  of  impairments. 
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Description:  Observation_12 


EBBED 


Property  assertions:  Observation_12 


UBS  ED 


Types  ^p 

Object  property  assertions 

%  datamodehObservation 

i  cfa:hasFocus  cfa:trunk_flexion_initial 

■  cfa:hasValue  dbq:degree_80 

Same  Individual  As 

Data  property  assertions 

Different  Individuals 

■  cfaihasID  "000-00-0000"A Axsd:string 

Negative  object  property  assertions  Cp 

Figure  8.  Modeling  of  collected  data  as  an  Observation. 


►  0  icf:ICFCategorY 

►  #  kf:ICFQualifier 
▼  #  ICFCode 

#  ICFActivityAndParticipationCode 

#  ICFBodyFunctionCode 
|#  ICFBodyStructureCode 

0  ICFE  nviron  mental  Fa  ctorCode 


•  ICFCode 

0  hasExtentOflmpairment  some  icf:Q_Extent_of_lmpairment 
0  hasLocationOflmpairment  some  icf:Q_Anatomical_Localization 
0  hasNatureOflmpairment  some  icf:Q_Nature_of_Change_in_Body_Structure 

0  hasCategoryCode  some  icf:ICFCategory 


Figure  9.  Model  for  ’’Body  Structure”  ICF-coded  data. 


To  facilitate  the  use  of  Semantic  Web  Rule  Language  (SWRL)  rules  to  perform  the  mapping  from  CFA-CL  to 
ICF,  we  first  created  a  mapping  structure  CFA2ICFMapping  (Figure  10),  where  a  CFA  entity  (e.g.,  an 
assessment  term  or  a  qualifier  term)  is  mapped  to  the  corresponding  ICF  category  or  qualifier  value. 


CLASS  EDITOR  for  CFA2ICFMapping  (instance  of  owhClass) 


http://purl.Org/facsimile/cfa-icf.owl#CFA2ICFMapping 

^  tBu  J 


CD  Inferred  View 

D  Annotation* 


Property  Value  Lang 

□  rdfs:comment  Mapping  structure  for  specifying  how  individual  CFA-CL  entities 
map  to  ICF  entities  (categories  and  qualifiers). 


WIW 


Asserted  Condition* 

—  NECESSARY  A  SUFFICIENT 


#  owIThing 

©  (hasICFEntity  only  icf:ICFCategory)  or  icf:ICFQualifier 
0  hasCFAEntity  some  (cfa:DataElementDescription  or  cfa:ValueSet) 
0  hasICFEntity  some  (icf:ICFCategory  or  krf:ICFQualifier) 

0  hasMappingType  some  MappingType 


c 


c 


c 


c 


c 


Figure  10.  Mapping  structure  for  translating  CFA-CL  coded  data  to  ICF-coded  data. 

We  modeled  the  mapping  from  the  CFA-CL  data  format  to  the  ICF  data  format  as  a  collection  of  SWRL  rules. 
An  example  is  shown  in  Figure  1 1.  It  takes  an  Observation  instance  that  encodes  a  body-function  assessment 
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(e.g.,  right  knee  extension  of  5  degrees)  and  mappings  from  CFA-CL  to  ICF  (e.g.,  the  notion  of  extension  to 
“b7100  Mobility  of  a  single  joint”)  and  that  of  5  degrees  to  “3.  SEVERE  impairment  (high,  extreme,  ...)  50-95 
%”  to  create  an  instance  of  ICFBodyFunctionCode  that  denotes  the  mapped  values  as  the  combination  of  the 
ICF  category  and  the  ‘extent  of  impairment’  qualifier.  To  create  the  new  ICF-coded  data,  we  used  Protege’s 
SWRL  extension  built-in  swrlximakeOWLIndividual,  which  is  not  one  of  the  standard  SWRL  built-ins. 

0  O  O  SWRL  Rule 


Comment 


Name 


http://purl.0rg/facsimile/cfa-icf.0wl#B0dyFuncti0nMapping 


SWRL  Rule _ 

datamodel:Observation(?o)  a  cfa:hasFocus(?o,  ?f)  a  cfa:hasValue(?o,  Tv)  a  cfa:haslD(?o,  ?id)  a  cfa:FunctionalAssessment(?f)  a 
CFA2ICFMapping(?mapl)  a  CFA2ICFMapping(?map2)  a  hasCFAEntity(?mapl,  ?f)  a  haslCFCategory(?mapl,  ?icfCategory)  a 
hasMappingType(?mapl,  Ttypel)  a  hasCFAEntity(?map2,  Tv)  a  haslCFQualifier(?map2,  ?icfQualifier)  a 
hasMappingType(?map2,  ?type2)  a  'ICF  Category'(?icfCategory)  a  'Extent  or  magnitude  of  impairment'(?icfQualifier)  a 
swrlx:makeOWLIndividual(?o,  ?icfCode) 

ICFBodyFunctionCode(?icfCode)  a  haslCFCategory(?icfCode,  ?icfCategory)  a  hasExtentOflmpairmentC?icfCode,  TicfQualifier) 
a  hasMappingType(?icfCode,  Ttypel)  a  hasMappingType(?icfCode,  ?type2)  a  haslD(?icfCode,  |?id) 


Figure  1 1.  A  SWRL  rule  for  creating  ICF-coded  data  from  CFA-CL-coded  body-function  data. 

Because  ICF  uses  multiple  codes  to  represent  a  single  disability,  we  needed  to  write  additional  rules  to  translate 
the  CFA-CL  data  to  a  set  of  ICF  codes.  For  the  example  of  “right  knee  extension”  observation,  we  used  a 
second  rule  to  generate  the  ICF  body  structure  code  (Figure  12).  Note  that  we  used  an  observation  ID  to 
indicate  that  the  ICF  body  function  and  body  structure  codes  are  derived  from  the  same  CFA-CL  observation. 


BOO  SWRL  Rule 


Comment 


Name 


http://purl.0rg/facsimile/cfa-icf.0wl#B0dyStructureMapping 


SWRL  Rule 

datamodel:Observation(?o)  a  cfa:hasFocus(?o,  ?f)  a  cfa:haslD(?o,  ?id)  a 
cfa:hasAnatomicalLocationCode(?o,  ?anatloc)  a  cfa:  has  Late  ralityCTf,  ?lat)  a 

cfa:FunctionalAssessment(?f)  a  CFA2ICFMapping(?mapl)  a  CFA2ICFMapping(?map2)  a  hasCFAEntity(?mapl,  ?anatloc)  a 
haslCFCategory(?mapl,  ?icfbody)  a  hasMappingType(?mapl,  Ttypel)  a 

hasCFAEntity(?map2,  ?l at)  a  haslCFQualifier(?map2,  TicfQualifier)  a  hasMappingType(?map2,  Ttype2)  a 
'ICF  Category'(?icfbody)  a  icf:Q_Anatomical_Localization(?icfQualifier)  a  swrlx:makeOWLIndividual(?o,  TicfCode)  -* 
ICFBodyStructureCode(?icfCode)  a  haslCFCategory(?icfCode,  Ticfbody)  a  hasLocationOflmpairment(?icfCode,  TicfQualifier) 
a  hasMappingType(TicfCode,  Ttypel)  a  hasMappingType(TicfCode,  Ttype2)  a  haslD(TicfCode,  Tid) 


Figure  12.  A  SWRL  rule  to  map  the  anatomical  location  of  a  body  function  assessment  to  ICF  code. 


7.  We  will  create  a  developmental  de-identified  data  set  that  contains  musculoskeletal 
functional  assessment.  We  will  code  the  functional  assessments  using  CFA-CL,  and 
translate  them  to  ICF-coded  data. 
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As  detailed  in  our  report  for  Task  1,  it  was  impossible  to  create  de-identified  data  sets  from  the  Madigan  Army 
Medical  Center  archive.  Instead,  we  developed  the  CFA-CL  for  the  possibility  of  capturing  data  prospectively 
and  we  did  not  rely  on  the  availability  of  de-identified  data  retrospectively. 


8.  We  will  define  a  set  of  queries  that  are  interesting  from  the  perspectives  of  evaluating 
individuals  and  of  performing  aggregated  analysis.  We  will  demonstrate  the  ability  to 
make  these  queries  on  the  developmental  data  set. 

From  our  interviews  at  Madigan  AMC,  we  came  to  the  conclusion  that  Madigan  providers  are  intensely  focused 
on  the  evaluation  of  individual  service  members,  and  have  little  interest  in  queries  of  aggregated  data. 

Given  our  focus  current  focus  on  the  DBQs,  the  queries  that  are  most  interesting  from  the  perspective  of 
evaluating  individuals  involve  criteria  from  the  Schedule  for  Rating  Disabilities  used  in  IDES  to  determine  a 
numeric  disability  rating  for  the  purpose  of  calculating  the  disability  benefit.  The  criteria  in  the  Rating  Schedule 
are  closely  tied  to  questions  in  the  DBQs.  With  our  modeling  of  DBQ  questions,  we  were  able  to  answer  such 
queries.  For  example,  page  398  of  the  Schedule  for  Rating  Disabilities  states  that,  for  an  10  percent  disability 
rating,  the  service  member  should  have,  among  possible  alternatives, 

muscle  spasm,  guarding,  or  localized  tenderness  not  resulting  in  abnormal 
gait  or  abnormal  spinal  contour; 

These  criteria  are  directly  related  to  questions  in  the  example  DBQ  for  the  back  (thoracolumbar  spine)  (Figure 
13).  In  the  CAF-CL  ontology,  we  have  a  data  element  description  for  the  finding  Guarding  or  Muscle  Spasm  of 
the  Thoracolumbar  Spine ,  and,  if  a  clinician  populates  the  DBQ  form  generated  from  this  project,  the  result  is 
coded  data  of  which  the  focus  is  this  data  element. 

7B.  DOES  THE  VETERAN  HAVE  GUARDING  OR  MUSCLE  SPASM  OF  THE  THORACOLUMBAR  SPINE  (back)? 
□  YES  □  NO  IF  YES,  IS  IT  SEVERE  ENOUGH  TO  RESULT  IN:  (check  all  that  apply) 

|  Abnormal  gait 

I  I  Abnormal  spinal  contour,  such  as  scoliosis,  reversed  lordosis,  or  abnormal  kyphosis 
I  I  Guarding  or  muscle  spasm  does  not  result  in  abnormal  gait  or  spinal  contour 

Figure  13.  A  question  in  the  DQB  on  the  back  (thoracolumbar  spine)  conditions 

With  data  coded  in  the  CFA-CL  Semantic  Model  that  makes  use  of  ICF  concepts,  we  can  make  aggregated 
queries  such  as  most  common  disabilities  associated  with  ICF  code  s7501  (structure  of  lower  leg).  We  can 
aggregate  disabilities  to  any  level  and  sort  by  frequency.  With  these  queries,  we  can  identify  the  prevalence  of 
specific  problems  (e.g.,  foot  problems)  that  can  be  ameliorated  with  better  equipment  (e.g.,  change  shoes, 
different  inserts). 

In  Task  15,  we  demonstrated  the  ability  to  make  such  queries. 

If  we  link  CFA-CL  data  with  other  data  sets,  we  can  perform  much  more  interesting  queries.  For  example,  with 
appropriate  data  sets,  we  can  mine  for  associations  between  functional  assessments  and  the  risk  of  homelessness 
after  discharge  or  between  amputation  and  incidence  of  diabetes.  We  can  identify  the  need  for  home  support 
(e.g.,  the  need  for  aid  and  attendance)  based  on  functional  losses.  These  possibilities  indicate  the  potential  for 
using  structured  functional  assessment  data,  but  creating  such  data  sets  is  outside  the  scope  of  this  project. 

9.  We  will  specify  the  IDES  task  for  which  we  will  demonstrate  the  use  of  CFA-CL— coded 
data. 

We  analyzed  the  criteria  in  the  retention  and  rating  standards.  While  many  of  these  criteria,  such  as  those  related 
to  range  of  motion,  can  be  matched  precisely  from  structured  data,  others,  such  as  “Loss  of  toes  that  precludes 
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the  abilities  to  run  or  walk  without  a  perceptible  limp  and  to  engage  in  fairly  strenuous  jobs”  require  subjective 
judgment  to  identify.  We  may  not  be  able  to  match  such  criteria  with  the  data  collected  through  any  assessment 
instruments.  Therefore,  we  believe  that  at  most  we  can  index  the  criteria  with  relevant  codes,  and  that  we  can 
use  the  coded  data  for  an  individual  subject,  once  the  data  become  available,  to  focus  attention  on  those  criteria 
that  may  be  relevant  to  that  subject. 

Given  the  unavailability  of  structured  CFA  data,  we  focused  on  the  task  of  developing  methods  to  acquire  EHR- 
compatible  structured  data  through  assessment  forms.  Our  modeling  of  components  of  assessment  forms  is 
similar  to  LOINC’s  approach,  including  the  division  into  sections  and  questions,  and  the  definition  of  possible 
answers  to  the  questions.  However,  our  work  extends  the  LOINC  representation  by  modeling  the  semantic 
content  of  the  questions  by  giving  these  questions  formal  definitions  in  terms  of  a  Clinical  Functional 
Assessment  (CFA)  ontology,  represented  in  OWL.  The  CFA  ontology  provides  concepts  and  relationships  that 
allow  us  to  give  formal  descriptions  of  the  findings,  assessments,  and  measurements  embodied  in  the 
assessment  instruments.  From  the  model  of  assessment  instruments,  we  generate  Web-based  data-acquisition 
forms,  through  which  clinicians  can  easily  document  necessary  assessments.  The  backend  of  our  tool 
automatically  generates  structured  data  in  multiple  formats.  The  data  can  be  post-processed  into  formats 
consistent  with  those  of  Health  Level  7  via  simple  transformations,  and  made  available  for  querying  and 
aggregation. 

10.  We  will  complete  CFA-CL  V0.5. 

We  define  CFA-CL  0.5  as  a  framework  for  defining  the  semantic  content  of  the  assessment  questions  and 
answers  by  giving  these  questions  and  answers  formal  definitions  in  terms  of  a  Clinical  Functional  Assessment 
(CFA)  ontology.  The  CFA  ontology  provides  concepts  and  relationships  that  allow  us  to  give  formal 
descriptions  of  the  findings,  assessments,  and  measurements  embodied  in  the  assessment  instruments.  In 
addition,  we  developed  information  models  for  such  instruments  and  for  data  captured  in  the  instruments.  The 
CFA  ontology  and  information  models  inform  the  generation  of  data-acquisition  forms  and  the  resulting  data 
can  be  queried  and  aggregated.  Our  ontologies  reference  the  ICF  and  other  reference  terminologies  such  as 
SNOMED  CT.  In  order  to  allow  generalization  of  this  framework  to  other  clinical  domains,  we  created  separate 
ontology  files  that  can  be  re-used  independently.  In  our  specific  application  we  use  the  full  import  closure  as 
depicted  in  Figure  14.  See  appended  paper  “Structured  Data  Acquisition  with  Ontology-Based  Web  Forms”  for 
detailed  descriptions  of  the  ontologies.  Here  we  briefly  describe  the  structure  of  the  CFA  ontology. 


Querying  and 
classification 


Functional  assessment 


- owl :  imports - ► 


Figure  14.  Import  structure  of  ontologies  developed  as  part  of  CFA-CL  and  its  application  to  structured  data 
acquisition  through  generated  forms. 

The  CFA  ontology  is  divided  into  three  main  branches:  (1)  DataElementDescription  that  defines  a  Finding  (the 
result  of  an  observation,  measurement,  or  judgment,  (2)  ValueSet  that  defines  collections  of  possible  qualifiers 
and  values  for  findings,  and  (3)  SubjectMatter Ontology  that  provides  internally  defined  domain  concepts  that 
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either  are  not  available  in  standard  terminologies  or  are  references  to  standard  terms  that  need  to  be  organized 
into  taxonomies.  The  Finding  class  is  further  subdivided  into  Assessment  (those  findings  that  have  non-numeric 
results)  and  Measurement  (those  findings  that  have  numeric  results).  We  also  define  FunctionalAssessment  (a 
subclass  of  Assessment).  In  general,  a  functional  assessment  will  have  some  assessed  function  that  can  be 
related  to  an  ICF  body  function  or  activity  (possibly  as  an  exact  match,  specialization,  or  generalization),  some 
assessed  attribute,  such  as  severity,  that  specifies  the  dimension  of  the  function  being  assessed,  and,  optionally, 
some  anatomical  location  of  the  assessment.  Findings  and  functions  can  be  modified  by  qualifiers  that  further 
refine  these  entities.  For  example,  a  functional  assessment  may  be  made  in  the  context  of  using  assistive 
devices,  and  a  function  being  assessed  may  have  some  temporal  component  (e.g.,  constant  pain).  CFA  imports 
a  version  of  ICF  that  is  represented  in  OWL.  Thus,  all  ICF  categories,  such  as  ‘body  structure’,  ‘body  function’, 
‘activities  and  participation’,  and  ‘environmental  factors’  are  available  for  formalizing  descriptions  of 
functional  assessments.  For  other  standard  terminologies  such  as  SNOMED  CT,  ICD,  and  LOINC,  instead  of 
importing  them  as  ontologies,  we  make  references  to  them  through  instances  of  Externally  CodedValue. 

11.  We  will  obtain  de-identified  data  for  demonstration  purpose. 

As  detailed  in  our  report  for  Task  1,  it  is  impossible  to  create  de-identified  data  sets  from  the  Madigan  Army 
Medical  Center  archive.  We  developed  the  CFA-CL  for  the  possibility  of  capturing  data  prospectively  and  we 
are  not  relying  on  the  availability  of  de-identified  data  retrospectively. 

12.  We  will  model  CFA-CL  V0.5  as  parameterized  constraints  on  ICF  semantic  model 

ICF  concepts  are  organized  into  components  such  as  body  structure ,  body  function ,  activity  and  participation , 
and  environmental  factors.  We  integrate  ICF  concepts  directly  into  descriptions  of  data  elements.  First,  we  use 
ICF’s  body  structures  as  our  default  source  ontology  for  anatomical  locations.  Second,  we  specify  how  the 
function  being  assessed  is  related  to  ICF  functions  using  the  properties  isExactMatchOf  isGeneralizationOf 
and  isSpecializationOf.  Third,  we  represent  ICF  qualifiers  as  either  attributes  being  assessed  (e.g.,  severity)  or 
as  qualifiers  that  modify  the  meaning  of  the  functional  assessment  description  (e.g.,  laterality  modifying  the 
anatomical  location  of  the  function  being  assessed).  For  example,  “severity  of  constant  pain  on  the  lower  left 
extremity  cased  by  radiculopathy”  would  be  modeled  as  shown  in  Figure  15. 


Description:  constant_pain_left_lower_extremit 


•  hasAnatomicalLocation  some 

('s750.  Structure  of  lower  extremity' 
and  (hasLaterality  value  Left)) 

•  hasAssessedFunction  some 

(Function 

and  (isExactMatchOf  some  'b2801.  Pain  in  body  part’) 
and  (causedBy  value  Radiculopathy) 
and  (hasQualifier  value  Constant)) 

•  measuredOrAssessedAttribute  value  severity 

Figure  15.  Modeling  of  the  data  element  severity  of  constant  pain  on  the  lower  left  extremity  cased  by 
radiculopathy”. 


13.  We  will  convert  CFA-CL  V0.5  codes  to  ICF  coding  format. 

In  Task  6,  we  showed  a  SWRL  mapping  approach  to  convert  CFA-CL  to  ICF  coding  format.  This  approach  has 
several  disadvantages.  First  it  requires  that  we  come  up  with  mapping  functions,  such  as  those  that  convert  data- 
element— specific  severity  scales  to  the  one  used  in  the  ICF  coding  scheme,  that  are  difficult  to  justify.  Second, 
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translating  data  elements  into  ICF-coded  format  is  feasible  only  for  functional  assessment  data,  and  thus  such  a 
translation  places  ICF-specific  and  non-ICF  data  into  different  data  models,  complicating  queries  that  may  join 
functional  and  non-functional  assessment  data.  Non-ICF  descriptors  (e.g.,  attributes  such  as  “intermittent”  or 
“constant”  that  are  used  to  qualify  functional  assessments  cannot  be  represented  in  the  ICF  coding  format. 
Finally,  the  use  of  SWRL  rules  to  translate  data  from  one  format  to  another  requires  the  use  of  non-standard 
extensions  of  SWRL  that  is  available  only  in  earlier  versions  of  the  Protege  tool  that  we  use.  For  this  milestone, 
we  explored  an  alternative  approach,  as  described  in  Task  12,  where  the  mapping  to  ICF,  when  appropriate,  is 
directly  specified  in  the  description  of  data  elements  (Figure  8). 

In  this  approach,  CFA-CL  data  are  represented  as  instances  of  Observations  with  a  focus  (a  reference  to  the 
CFA-CL  description  of  a  data  element)  and  a  value  (e.g.,  see  Figure  8).  The  reference  to  the  CFA-CL 
description  of  a  data  element  allows  us  to  make  detailed  queries,  as  is  described  in  Task  15. 

Not  translating  data  into  pure  ICF-coded  format  means  that  we  cannot  aggregate  data  across  multiple  data 
elements  using  ICF-imposed  uniform  qualifier  values.  Given  the  problems  with  such  mappings  (e.g.,  from 
degrees  of  extensions  or  rotations  to  a  uniform  0-4  scale  representing  ‘no  impairment’  to  ‘complete  impairment 
96-100%),  such  aggregation  is  probably  not  very  meaningful  anyway. 

14.  We  will  develop  software  for  the  application  of  CFA-CL  V0.5  data  to  demonstration 
tasks . 


See  Appendix  “Structured  Data  Acquisition  with  Ontology-Based  Web  Forms.” 

15.  We  will  apply  and  analyze  the  application  of  CFA-CL  V0.5  to  the  demonstration  task. 


See  Appendix  “Structured  Data  Acquisition  with  Ontology-Based  Web  Forms.” 


16.  We  will  write  the  final  report  and  package  software,  model  artifacts,  and  sample  data 


4.  Key  Research  Accomplishments 

•  We  have  come  to  the  conclusion  that  current  documentation  practices  in  centers  such  as  Madigan  AMC 
pose  difficulties  in  codifying  clinical  functional  assessments  as  structured  data. 

•  We  have  identified  as  a  problem  a  lack  of  structured  functional  assessment  data  because  there  is  no 
standard  data  representation  that  is  in  use.  Yet  the  representation  we  are  creating  is  difficult  to  evaluate 
because  of  the  lack  of  data.  A  strategy  to  break  the  chicken-and-egg  problem  of  data  representation  and 
data  capture  is  to  instrument  systems  for  entering  form-based  data  so  that,  as  data  are  entered  into  forms, 
they  are  automatically  transformed  into  our  underlying  models. 

•  We  found  that  DBQs,  the  criteria  in  the  MOS  Manual  and  in  the  military  retention  standards  require  very 
specific  functional  assessments,  which  are  difficult  to  map  to  ICF.  There  is  no  Rosetta  Stone  for  translating 
neatly  among  these  different  data  elements.  What  we  can  accomplish  is  to  create  a  set  of  models  that 
provides  a  mechanism  for  representing  diverse  data  related  to  functional  assessment. 

•  We  found  that,  when  the  goal  is  to  automate  the  capture  of  structured  functional  assessment  data,  the 
particular  syntax  that  we  initially  proposed  is  not  necessary.  Instead  the  data  can  be  structured  in  a 
semantically  sound  representation  that  facilitates  queries  and  transformations. 

•  For  the  goal  of  capturing  structured  clinical  functional  assessment,  we  have  created  a  semantic  model  of 
data  element  descriptions  and  a  framework  for  using  these  descriptions  to  structure  data. 
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•  The  modeling  contributions  include  (1)  CFA:  a  clinical  functional  assessment  domain  ontology  that  allows 
defining  questions  being  asked  in  an  assessment  instrument  in  terms  of  a  rich  ontology  that  integrates 
standard  terminologies  such  as  ICF  and  SNOMED  CT,  and  which  provides  the  means  for  making  detailed 
or  aggregate  queries  on  acquired  data,  and  (2)  a  data  model:  an  information  model  that  allows  the 
specification  of  generic  assessment  forms  and  the  format  of  structured  data  acquired  through  the 
instruments.  We  have  designed  our  output  model  to  support  the  acquisition  of  structured  data  through  Web 
forms,  and  for  the  potential  to  integrate  the  data  inside  EHRs.  It  is  straightforward  to  transform  the  data  we 
capture  as  instances  of  Observation,  Certification,  Evaluatorlnformation,  and  Subjectlnformation  into,  for 
example,  Health  Level  Seven  (HL7)  Reference  Information  Model  (RIM)  standard  compliant  data. 

•  We  developed  the  technology  to  generate  forms  for  acquiring  structured  data  based  on  the  models  forms, 
questions,  and  CFA  CL  data  elements.  The  aggregated  input  gathered  through  these  forms  can  be  exported 
to  databases  and  queried  using  standard  SQL  or  can  be  represented  an  ontology  of  “semantically-enriched” 
form  data  that  can  be  queried  using  an  RDF  query  language,  such  as  SPARQL 


5.  Conclusion 

We  have  created  a  semantic  framework  for  modeling  structured  functional-assessment  data  and  showed  how  such 
data  can  be  derived  from  assessment  instruments  such  as  DBQs.  We  have  created  mapping  structures  and  rules  to 
transform  data  represented  in  this  framework  to  ICF-coded  format. 

We  demonstrated  (1)  how  to  generate  forms  and  acquire  data  based  on  the  ontologies  and  data  models  in  this 
semantic  framework,  and  (2)  how  to  make  use  of  the  data  using  queries  on  individual  subjects  and  queries  that 
aggregate  population  data. 
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assessment  using  standard  terminologies.  AMIA  Annual  Conference.  San  Francisco,  CA,  2015,  submitted. 
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Abstracts: 
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7.  Inventions,  Patents,  and  Licenses 

Nothing  to  report 

8.  Reportable  Outcomes 

We  have  created  a  semantic  model  for  clinical  functional  assessment  consisting  of 

•  An  ontology  of  functional  assessment  data  element  descriptions 

•  An  information  model  of  assessment  instruments  and  its  components 

•  A  data  model  for  assessment  data,  in  CFA-CL  and  ICF  formats 

We  developed  a  mechanism  that  employs  non-obtrusive  ontology-based  Web-forms  to  encode  key  functional 
assessment  data,  using  terms  from  ICF  and  other  standard  terminologies.  This  solution  allows  us  to  query  and 
aggregate  the  resulting  structured  data,  based  on  standardized  descriptions  of  assessment  data  elements.  Our  solution 
can  advance  adoption  of  standard  terminologies,  facilitate  health  information  exchange  and  clinical  decision  support, 
and  bring  to  bear  the  full  power  of  modern  electronic  health  records. 
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ABSTRACT 

Structured  data  acquisition  is  a  common,  challenging  task  that 
is  widely  performed  in  the  field  of  biomedicine.  However,  in  some 
biomedical  fields,  such  as  clinical  functional  assessment,  little  effort 
has  been  done  to  structure  functional  assessment  data  in  such  a 
way  that  it  can  be  automatically  employed  in  decision  making  (e.g., 
determining  eligibility  for  disability  benefits)  based  on  conclusions 
derived  from  acquired  data  (e.g.,  assessment  of  impaired  motor 
function).  In  order  to  be  able  to  apply  such  automatisms,  we  need 
data  structured  in  a  way  that  can  be  exploited  by  automated  deduction 
systems,  for  instance,  in  the  Web  Ontology  Language  (OWL);  the 
de  facto  ontology  language  for  the  Web.  The  rise  of  OWL  caused 
a  paradigm  shift  in  knowledge  systems  from  frame-based  to  axiom- 
based.  Because  of  the  axiom-based  nature  of  OWL,  it  is  more 
difficult  to  acquire  instance  data  based  on  OWL  than  it  was  based 
on  frames.  In  this  paper  we  tackle  the  problem  of  generating  Web 
forms  from  OWL  ontologies,  and  aggregating  input  gathered  through 
these  forms  as  an  ontology  of  “semantically-enriched”  form  data  that 
can  be  queried  using  an  RDF  query  language,  such  as  SPARQL. 
The  ontology-based  structured  data  acquisition  framework  that  we 
have  developed  is  presented  through  its  specific  application  to  the 
clinical  functional  assessment  domain,  with  examples  of  how  one  can 
perform  desirable  analyses  of  gathered  data  with  simple  queries. 

1  INTRODUCTION 

Ontology-based  form  generation  and  structured  data  acquisition 
was  first  pioneered  almost  30  years  ago.  In  the  early  1990s, 
Protege-Frames  used  definitions  of  classes  in  an  ontology  to 
generate  knowledge-acquisition  forms,  which  could  be  used  to 
acquire  instances  of  the  classes  [2,  3].  With  OWL  as  the  preferred 
modeling  language  for  ontologies,  class  definitions  are  collections 
of  description  logic  (DL)  axioms,  and  can  no  longer  be  seen 
as  templates  for  forms  [9].  Unlike  template-based  knowledge 
representations,  where  what  can  be  said  about  a  class  is  defined 
by  the  slots  of  the  class  template,  axiom-based  representations  do 
not  have  this  kind  of  locally  scoped  specification,  and  allow  any 
axiom  describing  the  same  class  to  be  added  to  the  ontology,  as 
long  as  the  axiom  does  not  lead  to  inconsistencies.  Template-based 
knowledge  representation  systems  use  closed- world  reasoning  and 
have  local  constraints  (e.g.,  cardinality  of  a  slot  for  a  particular 
class)  that  can  be  validated  easily,  while  in  an  axiom-based  system 
with  the  open-world  assumption  such  local  constraint  checking  is 
much  more  problematic.  Furthermore,  in  our  chosen  application 
domain,  assessment  instruments  have  specific  formats  that  do  not 
lend  themselves  to  be  seen  as  representing  instances  of  domain 
ontology  classes.  Items  in  the  instruments  have  potentially  complex 
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descriptions  of  information  to  be  collected,  such  as  the  severity  of 
pain  with  a  particular  quality,  and  at  a  specific  anatomical  location. 
The  challenge  is  to  model  the  assessment  instruments  and  relate  the 
assessed  data  to  a  domain  ontology  with  which  one  can  formulate 
meaningful  queries. 

In  this  paper,  we  describe  a  solution  for  representing,  acquiring 
and  querying  assessment  data  that  uses  (1)  domain  ontologies  and 
standard  terminologies  to  give  formal  descriptions  of  entities  in  our 
chosen  domain,  (2)  an  information  model  of  assessment  instruments 
to  drive  the  generation  of  data- acquisition  Web  forms,  and  (3) 
a  data  model  for  the  acquired  information  that  links  the  data  to 
the  domain  ontologies  and  standard  terminologies.  Such  linkage 
makes  it  possible  to  query  and  aggregate  the  data  using  the  logical 
representation  of  the  domain  concepts  in  the  ontologies. 

2  RELATED  WORK 

In  addition  to  the  comparison  with  Protege-Frames’  template-based 
instance  acquisition  method  described  in  Section  1,  we  briefly 
contrast  our  work  with  two  other  systems  that  are  designed  to  use 
forms  for  acquiring  structured  data:  the  first  targets  the  domain  of 
patient  assessment,  which  is  similar  to  the  work  reported  here,  while 
the  second  is  a  generic  Web-based  technology  from  which  one  can 
draw  examples  on  how  to  arrive  at  a  domain-independent  solution. 

The  clinical  documentation  system  described  in  [6]  uses  a 
template  schema  to  allow  a  technology-savvy  clinician  to  create 
documentation  templates  that  include  the  local  structure  of 
subforms  and  potentially  complex  clinical  descriptions  consisting 
of  features  and  their  values.  The  features  and  values  are  mapped 
to  a  medical  ontology,  and  the  system  automatically  generates 
ontological  descriptions  of  the  data  elements  based  on  the  mappings. 
Constrained  by  our  goal  to  replicate  existing  forms,  we  took  the 
opposite  approach  where  we  start  with  ontological  descriptions 
of  the  data  elements,  specify  how  they  are  used  in  assessment 
instruments  as  part  of  the  description  of  instruments,  and  generate 
Web  forms  for  the  acquisition  of  data.  Having  the  freedom  to  design 
their  documentation  system,  Horridge  et  al.  avoided  the  laborious 
work  of  manually  modeling  the  domain  concepts. 

Semantic  wikis  extend  regular  wikis  with  semantic  technologies, 
wherein  each  wiki  article  is  an  RDF  resource,  and  an  instance 
of  some  resource  such  as  a  class  defined  in  the  schema,1  which 
can  be  asserted  to  have  relations  with  other  RDF  resources.  These 
relations  are  defined  by  the  authors  of  wiki  articles,  which  could 
be  a  challenging  task  to  perform  without  previous  knowledge  of  the 
domain  or  the  modeling.  In  a  survey  of  semantic  wikis  featuring 
OWL  reasoning  and  SPARQL2  querying  facilities  [4],  a  user 


1  The  typical  kinds  of  schema  accepted  are  OWL  and  RDFS. 

^  http : //www . w3 . org/TR/rdf- sparql- query 
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evaluation  of  a  chosen  semantic  wiki  implementation  concluded  that 
authoring  instance  data  in  such  a  way  is  cumbersome,  even  with 
users  that  were  familiar  with  ontologies.  A  good  solution  to  this 
would  be  exploiting  the  relations  defined  in  the  schema  to  provide 
“wiki  article  templates”  whose  form  input  fields  derive  from  those 
relations,  thus  making  it  easier  to  author  semantic  wiki  articles. 

3  APPLICATION  DOMAIN 

Clinical  functional  assessment  provides  the  application  motivation 
for  our  work.  Functional  assessment  is  the  evaluation  of  an 
individual’s  ability  to  perform  body  functions  (e.g.,  flexing  a  joint) 
and  defined  tasks  (e.g.,  walking  a  specific  distance).  It  is  necessary 
for  evaluating  disabilities  for  rehabilitation,  for  social  security 
payment,  or  for  decisions  to  retain  or  discharge  service  members 
who  may  be  injured  on  duty.  Despite  its  importance,  it  is  not  usually 
supported  by  electronic  health  record  (EHR)  systems  [1].  These 
assessments  are  often  documented  using  assessment  instruments 
(e.g.,  check-lists  and  validated  questionnaires)  such  as  Karnofsky 
Performance  Status  [11].  Too  frequently  the  data  derived  from  using 
these  instruments  are  saved  as  either  blobs  or  non-standard  data 
elements.  While  a  standard  such  as  LOINC®  (Logical  Observation 
Identifiers  Names  and  Codes)  defines  the  syntactic  structures  of 
assessment  instruments  as  a  hierarchy  of  panels  with  questions  that 
have  coded  answers  [10],  it  does  not  relate  the  semantic  content 
of  the  questions  and  answers  to  standard  terminologies  and  data 
models  that  allow  meaningful  querying  and  aggregation  of  acquired 
data. 

In  our  application  scenario  we  use,  as  exemplars,  the 
U.S.  Department  of  Veterans  Affairs  (VA)  Disability  Benefits 
Questionnaires  (DBQs).  DBQs  are  used  to  evaluate  service 
members’  disabilities  and  to  determine  the  benefits  for  which 
they  are  eligible.  We  start  off  with  these  DBQs  as  our  initial 
form  specifications,  and  design  an  ontology-based  method  for 
Web  form  generation  and  structured  data  acquisition,  subsequently 
exemplifying  how  one  would  go  about  exploiting  such  data  for 
immediate  or  post  facto  analyses. 

4  MODELING 

In  order  to  capture  the  semantic  distinctions  that  are  needed 
in  functional  assessment,  we  developed  a  Clinical  Functional 
Assessment  (CFA)  ontology  that  models  the  concepts  and 
relationships  that  occur  in  functional  assessment  instruments.  We 
developed  information  models  for  such  instruments  and  for  data 
captured  in  the  instruments.  We  will  show  how  the  CFA  ontology 
and  information  models  inform  the  generation  of  data-acquisition 
forms  and  how  the  resulting  data  can  be  queried  and  aggregated. 
Our  goal  was  to  develop  a  set  of  light-weight  ontologies  and 
models  with  minimal  ontological  commitments,  and  postponing 
alignment  with  possible  upper-level  ontologies  to  the  future. 
Existing  ontologies,  such  as  the  Information  Artifact  Ontology 
(IAO),3  do  not  provide  a  modeling  of  forms  and  questions  that  we 
could  reuse.  Furthermore,  what  we  need  is  an  information  model 
that  states,  for  example,  that  the  structure  of  a  “question”  includes 
a  specific  text,  not  an  ontology  that  models  parts  of  information 
artifacts  as  ontological  entities  (e.g.,  modeling  the  text  of  a  question 
as  an  instance  of  “textual  entity”  class).  Our  ontologies  reference  the 
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International  Classification  of  Functioning,  Disability  and  Health 
(ICF),4  developed  by  the  World  Health  Organization  (WHO),  and 
other  reference  terminologies  such  as  SNOMED  CT.5 

Imports  structure  The  modeling  tasks  of  this  project  involve 
describing  different  domain  areas,  leading  us  to  create  separate 
ontology  files  that  can  be  re-used  independently.  In  our  specific 
application  we  use  the  full  import  closure  as  depicted  in  Figure  1. 


Fig.  1:  Imports  structure  and  role  separation  of  ontologies  developed 
for,  or  included  as  part  of  our  modeling  solution.  Form  specifications 
use  terms  from  the  datamodel  ontology  (e.g.,  to  create  question 
instances)  as  well  as  from  domain- specific  ontologies  (e.g.,  CFA). 

The  ontology  marked  as  Instance  data  in  Figure  1  is  the 
collection  of  data  assertions  from  form  submissions,  possibly  from 
different  forms.  The  ontologies  represented  in  Form  specification 
are  specifications  of  different  forms;  in  our  case,  we  use  a  single 
ontology  that  specifies  two  closely-related  forms.  The  content  of 
the  above-mentioned  ontologies  is  application- specific,  that  is,  the 
way  the  data  is  represented  is  directly  derived  from  the  way  in 
which  forms  are  modeled  (for  different  assessment  instruments). 
However,  resulting  data  still  conform  to  the  generic  information 
models  specified  in  the  datamodel  ontology.  In  this  way,  there  is 
a  separation  of  the  Form  specification  ontologies  (Abox  axioms) 
from  the  Functional  assessment  ontologies  that  model  the  functional 
assessment  domain  and  data  models  (mostly  Tbox  axioms).  In 
Querying  and  classification  we  use  a  domain- specific  ontology  to 
apply  SWRL  rules,6  and  define  complex  OWL  classes  to  facilitate 
querying  in  SPARQL  and  in  OWL. 

ICF  ICF  is  a  multi-purpose  classification  that,  together  with 
the  International  Classification  of  Diseases  (ICD),7  is  a  reference 
classification  in  the  WHO  Family  of  International  Classifications 
(WHO-FIC).  It  provides  a  standard  language  and  conceptual  basis 
for  the  definition  and  measurement  of  functions  and  disability. 
However,  unlike  ICD  codes  that  represent  possible  disease  or 
injuries,  coding  different  health  and  health-related  states  requires 
that  ICF  codes  (e.g.,  “d4501”  -  walking  long  distance)  be  used 
in  conjunction  with  component- specific  qualifiers  (e.g.,  a  0  to 
4  scale  to  encode  the  range  of  impairment).  Such  a  complex 
coding  scheme  makes  it  difficult  to  transform  data  derived  from 
assessment  instruments  into  the  ICF  format.  Nevertheless,  ICF 
provides  a  reference  conceptual  basis  for  the  definition  and 
measurement  of  functions  and  disability,  thus  justifying  its  usage  in 
descriptions  of  functional  assessment  results,  despite  its  limitations 


^  http : //www . who . int / classifications /icf/en 

^  http : / /www . ihtsdo . org/snomed-ct 

^  http : / /www .w3.org/ Submiss ion/ SWRL 

7  http : / /www . who .int /classifications/ icd/en 
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as  a  formal  ontology  [7].  To  reference  ICF  concepts  in  our 
modeling  of  functional  assessment  descriptors,  we  use  a  version 
of  ICF  available  from  the  National  Center  of  Biomedical  Ontology 
(NCBO)  BioPortal  repository  [8],  that  is  represented  in  OWL. 

CFA  The  Clinical  Functional  Assessment  (CFA)  ontology  models 
concepts  and  relationships  that  allow  us  to  give  formal  descriptions 
of  the  findings,  assessments,  and  measurements  embodied  in 
clinical  functional  assessment  instruments.  The  ontology  is  divided 
into  three  main  branches:  (1)  Finding :  the  result  of  an  observation 
or  judgement,  (2)  Value  that  defines  collections  of  possible 
qualifiers  and  values  for  findings,  and  (3)  Sub jectMatter Ontology 
that  provides  internally  defined  domain  concepts  that  either  are  not 
available  from  standard  terminologies  or  are  references  to  standard 
terms  that  need  to  be  organized  into  taxonomies.  The  Finding 
class  is  further  subdivided  into  Assessment  (those  findings  that  have 
non-numeric  result)  and  Measurement  (those  findings  that  have 
numeric  results).  We  also  define  FunctionalFinding  (a  subclass  of 
Finding )  and  FunctionalAssessment  (a  subclass  of  Assessment).  In 
general,  a  functional  assessment  will  have  some  assessed  function 
that  can  be  related  to  an  ICF  body  function  or  activity  (possibly  as 
an  exact  match,  specialization,  or  generalization),  some  assessed 
attribute,  such  as  severity,  that  specifies  the  dimension  of  the 
function  being  assessed,  and  optionally  some  anatomical  location 
of  the  assessment.  Both  findings  and  functions  can  be  modified  by 
qualifiers  that  further  refine  these  entities.  For  example,  a  functional 
assessment  may  be  made  in  the  context  of  using  assistive  devices, 
and  a  function  being  assessed  may  have  some  temporal  component 
(e.g.,  constant  or  intermittent  pain).  ICF  being  an  imported  ontology 
for  CFA,  all  ICF  categories,  such  as  body  structure,  body  function, 
activities  and  participation,  and  environmental  factors  are  available 
for  formalizing  descriptions  of  functional  assessments.  For  other 
standard  terminologies  such  as  SNOMED  CT,  ICD,  and  LOINC, 
instead  of  importing  them  as  ontologies,  we  make  references  to  them 
through  an  ExternallyCodedValue  that  specifies  the  terminology 
source  and  code.  Queries  that  reference  these  codes  require  the 
availability  of  terminology  services  that  relate  these  codes  to  other 
terms  in  the  referenced  terminologies. 

The  modeling  of  Finding  is  exemplified  as  follows,  based  on 
the  “Back  (Thoracolumbar  Spine)  Conditions”  DBQ  that  we  use 
as  one  of  our  exemplar  assessment  instruments;  in  the  question  on 
the  severity  of  constant  pain  caused  by  radiculopathy  on  the  right 
lower  extremity,  we  define  a  subclass  of  FunctionalAssessment  that 
has  the  assessed  attribute  ‘severity’,  the  assessed  function  ‘icf:b2801 
Pain  in  body  part’  that  is  qualified  by  a  temporal  quality  ‘Constant’, 
and  has  anatomical  location  ‘icf:s750.  structure  of  lower  extremity’ 
with  laterality  ‘Right’.  Figure  2  illustrates  the  modeling  of  this 
assessment.  With  the  modeling  of  the  dimensions  of  assessment 
instrument  questions,  we  can  make  queries  on,  and  aggregate  data 
collected  through  the  instruments,  as  will  be  shown  in  Section  6. 

•  cfa^hasAnatomicaiLocation  some 

('icf:s750.  Structure  of  lower  extremity1 
arid  (cfa  :hasLaterality  value  cfa:Right)) 

•  cfa^hasAssessedFunction  some 

(cfa  ^Function 

and  (cfadsExactMatchOf  some  'icf:b2301.  Pain  in  body  part1) 
arid  (cfa:  caused  By  value  cfa:  Radiculopathy) 
and  (cfa :hasQualifier  value  cfa: Constant)) 

•  cfa :  Sever  ityOfPa  i  n  Sen  sati  on  Ca  u  sed  By  Ra  di  cu  I  opathy 

Fig.  2:  Modeling  of  “severity  of  constant  pain  caused  by 
radiculopathy  in  the  lower  right  extremity”. 


Datamodel  The  datamodel  ontology  is  a  generic,  context-free 
representation  of  a  form  (e.g.,  it  models  elements  such  as  questions 
and  sections)  and  the  data  generated  from  a  form  (e.g.,  a  string  value 
from  a  text  area,  or  values  from  an  enumerated  value  set).  Figure  3 
summarizes  key  aspects  of  our  modeling:  elements  of  a  form  are 
asserted  as  subclasses  of  FormStructure ,  such  as  Form ,  Section 
and  Question.  Each  kind  of  FormStructure  generates  some  kind  of 
Data ;  every  form  submission  generates  an  instance  of  FormData , 
which  references  (via  the  hasComponent  property)  all  instances  of 
Data  generated  in  the  process  of  parsing  form  answers.  Specific 
sections  such  as  SubjectlnfoSection  collect  information  pertaining 
to  a  subject,  and  these  details  are  aggregated  in  an  instance  of 
Subjectlnformation.  An  answer  to  an  instance  of  Question  gives  rise 
to  an  instance  of  Observation  with  a  hasValue  property  assertion 
to  the  IRI  of  the  selected  answer.  An  instance  of  Observation  will 
be  inferred  to  have  an  outgoing  hasFocus  property  assertion  if  the 
Question  instance  it  derives  from  encodes  some  kind  of  semantic 
description  of  the  question’s  meaning  via  the  is  About  relation.  Each 
instance  of  Question  specifies  a  set  of  possible  (answer)  values  via 
a  hasPossibleValue  relation  to  a  subclass  of  Value. 


Fig.  3:  Excerpt  of  the  datamodel  ontology  classes  and  relations. 


Form  The  Form  ontology  contains  the  set  of  individuals  that 
are  necessary  to  produce  forms.  While  the  technology  we  have 
developed  is  completely  generic,  we  use  as  exemplars  the  U.S. 
Department  of  Veterans  Affairs  (VA)  DBQs,  which  we  modeled 
in  an  ontology  named  DBQ.  This  ontology  contains  instances 
of  Question ,  Section ,  Form  and  other  elements  defined  in  the 
datamodel  ontology  (shown  in  Figure  3).  Not  only  does  this 
ontology  rely  on  datamodel  (for  form  structuring  purposes),  it  also 
relies  on  functional  assessment  classes  and  individuals  given  in  the 
CFA  ontology,  for  example,  values  of  a  scale  of  severity  of  pain 
that  should  be  presented  as  answer  options  to  users  reporting  on  the 
severity  of  constant  pain  in  the  lower  extremity. 

Criteria  The  criteria  ontology  contains  SWRL  rules  to  enrich  the 
domain  representation  (e.g.,  if  a  Question  instance  has  an  isAbout 
relation  with  some  instance  i,  then  the  Observation  data  instance 
that  represents  the  answer  to  that  question  will  get  a  hasFocus 
property  filler  z),  as  well  as  defined  classes  used  to  better  support 
querying,  which  we  describe  in  more  detail  in  Section  6. 
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5  OWL-BASED  DATA  ACQUISITION 

Our  approach  to  data  acquisition  in  OWL  requires  two  components: 
firstly,  an  OWL  representation  (in  the  form  of  one  or  more 
ontologies)  of  the  form  structures  (questions,  sections,  etc),  and 
descriptions  of  those  structures’  meanings,  and,  secondly,  the  view 
component  that  is  given  by  an  XML  file  specifying  user-interface 
aspects.  So,  in  order  to  use  our  method,  a  user  will  have  to  model 
questions  and  their  descriptions  in  OWL,  and  then  specify  the  layout 
and  content  of  the  resulting  form  in  XML. 

We  implemented  our  form  generation  and  data  acquisition  tool  in 
Java,  using  the  OWL  API  v4.0.1,8  and  its  source  code  is  publicly 
available  on  GitHub.9  The  tool  implementation  and  configuration 
details  are  omitted  here  due  to  lack  of  space,  but  can  be  found  in  the 
GitHub  project  wiki.  The  tool  takes  as  input  a  user-defined  XML 
configuration  file,  generates  a  form,  and  outputs  form  answers  in 
CSV,  RDF  and  OWL  formats.  The  configuration  file  should  contain 
a  pointer  to  the  ontology  specifying  the  form,  as  well  as  its  imports. 
The  two  major  stages  in  the  service  are  form  generation  and  form 
input  handling,  as  described  below. 

(1)  Form  generation  -  Steps  to  produce  a  form: 

(a)  Process  XML  configuration,  gathering  form  layout 
information,  IRIs  and  bindings  to  ontology  entities 

(b)  Extract  from  the  input  ontology  all  relevant  information 
pertaining  to  each  form  element: 

(b.l)  Text  to  be  displayed  (e.g.,  section  header,  question  text) 
(b.2)  Options  and  their  text,  where  applicable 
(b.3)  The  focus  of  each  question 

(c)  Generate  the  appropriate  HTML  and  JavaScript  code 

(2)  Form  input  handling  -  Once  the  form  is  filled  in  and  submitted: 

(a)  Process  answer  data  and  create  appropriate  individuals 

(b)  Produce  a  partonomy  of  the  individuals  created  in  (2.a)  that 
mirrors  the  layout  structure  given  in  the  configuration 

(c)  Return  the  (structured)  answers  to  the  user  in  a  chosen  format 

The  user-defined  XML  configuration  (l.a)  specifies:  input  and 
output  information  of  the  tool,  bindings  to  ontology  entities,  and 
layout  of  form  elements.  The  key  XML  elements  are: 

input :  contains  an  ontology  child  element,  and  optionally  a  child 
element  named  imports 

o  ontology :  absolute  path  or  URL  to  the  form  specification 
ontology  (e.g.,  DBQ  ontology) 

o  imports',  contains  ontology  child  elements,  which  have  an 
attribute  iri,  giving  the  IRI  of  the  imported  ontology 
output :  contains  the  following  child  elements 

o  file\  defines,  via  a  title  attribute,  the  title  of  the  form. 
Optionally,  a  path  can  be  specified  within  the  file  element 
where  the  HTML  form  file  should  be  serialized 

o  css  Style:  the  CSS  style  class  to  be  used  in  the  output  HTML 
bindings’,  defines  mappings  to  ontology  entities,  such  as  what  data 
property  is  used  to  state  the  text  of  a  question,  or  section  headings 
form :  defines  the  layout  and  behaviors  of  the  form 

There  is  a  wide  range  of  versatility  when  configuring  forms, 
such  as:  multiple  levels  of  sub-questions,  form  element  numbering, 


°  http://owlapi.sourceforge.net 
^  http : //github . com/protegepro ject/facsimile 


question  type  (e.g.,  radio,  checkbox,  dropdown,  horizontal 
checkbox,  etc),  question-list  layout  (vertical  or  inline)  and 
recurrence;  one  can  specify  that  a  collection  of  questions  should 
be  repeated  any  given  number  of  times.  Some  more  complex 
options  include  overriding  the  default  (alphabetic)  order  of 
answer  options,  and  triggering  sub-questions  when  a  specific 
answer  is  selected.  These  two  features  are  exemplified  in 
Figure  4:  this  question  is  configured  with  an  attribute/value 
pair:  showSubquestionsForAnswer=“ cfa:Yes”  on  the  question  XML 
element,  so  that  answering  ‘Yes’  triggers  the  sub-questions  of 
that  question.  In  Figure  4,  under  ‘Right  lower  extremity’,  we 
have  a  question  with  a  list  of  answer  options  derived  from 
an  enumerated  value  set,  which  would  ordinarily  be  ordered 
alphabetically.  However,  ‘None’  would  then  appear  between 
‘Moderate’  and  ‘Severe’,  thus  interrupting  a  severity  scale.  So 
we  added:  optionOrder=“ 3;*”  to  the  question  element,  which 
states  that  the  would-be  third  option  (alphabetically)  should  appear 
first,  and  the  remaining  (the  wild  character  stands  for  “all 
unmentioned  options”)  should  be  presented  in  default  order. 

Q  RADICULOPATHY 

A)  DOES  THE  VETERAN  HAVE  RADICULAR  PAIN  OR  ANY  OTHER  SIGNS  OR  SYMPTOMS  DUE  TO 

RADICULOPATHY?  (IF  YES,  COMPLETE  THE  QUESTIONS  BELOW) 

O  Yes  O  No 

Al)  INDICATE  SYMPTOMS*  LOCATION  AND  SEVERITY  (check  all  that  apply): 

Constant  pain  (may  be  excruciating  at  times) 

Right  lower  extremity: 

□  None  G  Mild  □  Moderate  O  Severe 

Fig.  4:  The  user  interface  of  the  form  generated  for  the  DBQ 
question  corresponding  to  radiculopathy  pain  modeled  in  Figure  2. 

The  key  output  of  the  data  acquisition  tool  is  the  OWL  ontology, 
as  it  provides  us  with  “semantically  enriched”  form  data  that  can  be 
used  for  aggregation  and  querying.  The  resulting  data  individuals 
are  structured  in  OWL  (via  hasComponent  relations)  similarly  to 
how  the  form  is  structured  in  the  configuration,  that  is,  if  question 
Q  is  configured  as  having  two  sub-questions,  then  the  Observation 
individual  generated  by  Q  will  have  two  outgoing  hasComponent 
relations  to  the  instances  of  Observation  generated  by  the  two  sub¬ 
questions  of  Q. 

6  DATA  ANALYSIS 

One  of  the  authors  (Michael  J.  Tierney),  who  is  a  physician  from 
the  YA  Palo  Alto  Healthcare  System,  validated  the  generated 
OWL-based  versions  of  the  DBQ  forms,  and  filled  in  the  “Back 
(Thoracolumbar  Spine)  Conditions”  DBQ  with  5  complete  sets  of 
sample  data.  The  data  gathered  are  stored  in  a  graph  database  with 
support  for  SPARQL  1.1  querying  and  OWL  2  reasoning. 

Since  our  data  are  both  structured  and  semantically  enriched,  we 
are  able  to  query  the  observations  using  SPARQL,  classify  them 
into  criteria  representing  powerful  OWL  expressions,  or  manipulate 
them  using  SWRL.  For  example,  Code  Snippet  1  presents  a  simple 
SPARQL  query  that  returns  all  instances  of  Observation  where  a 
patient  presented  signs  or  symptoms  due  to  radiculopathy.  It  is  worth 
observing  that  this  query  is  formulated  in  such  a  way  that  it  is 
independent  of  the  assessment  instrument,  including  the  particular 
formulation  of  the  question,  but  rather  uses  the  appropriate  focus 
individual  from  our  CFA  ontology. 
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Code  Snippet  1  SPARQL  query  for  retrieving  all  observations  of 
radicular  pain  due  to  radiculopathy. 

SELECT  ?obs  WHERE  { 

?obs  a  datamodel : Observation  . 

?obs  datamodel : isDerivedFrom  ?q  . 

?q  a  datamodel : Question  . 

?q  cfa:isAbout 

cf a : signs_or_symptoms_due_to_radiculopathy  . 

?obs  cfa:hasValue  cfa:Yes  } 


In  order  to  query  for  all  observations  of  severe  pain  anywhere  in 
the  lower  extremity,  one  could  formulate  an  OWL  DL  query  such  as 
that  given  in  Code  Snippet  2. 

Code  Snippet  2  OWL  DL  query  for  retrieving  all  observations  of 
severe  pain  anywhere  in  the  lower  extremity. 

datamodel : Observation  and 
cfa:hasValue  value  cfa: severe  and 
cfarhasFocus  some  (cfa : Assessment  and 
(cf a : hasAssessedFunct ion  some 
(cf a : isExactMatchOf  some 

'icf:b2801.  Pain  in  body  part'))  and 
(cf a : hasAnatomicalLocat ion  some 

'icf:s750.  Structure  of  lower  extremity')) 


In  response  to  the  query  in  Code  Snippet  2,  a  DL  reasoner  uses 
the  semantic  descriptions  of  the  observation  foci,  which  are  derived 
from  the  questions’  is  About  property,  to  aggregate  answers  for 
severe  pain  for  different  parts  of  the  lower  extremity. 

7  DISCUSSION 

In  this  paper  we  presented  a  framework  for  OWL-based  form 
generation  and  data  acquisition  that  gathers  form  answers  as  tab- 
delimited  data,  RDF  triples,  or  OWL  instances,  which  can  be 
subsequently  analyzed  in  a  systematic  way  (as  shown  in  our  queries 
in  Section  6).  Once  the  raw  data  is  processed  (by  deriving  the 
foci  of  observations  from  the  isAbout  field  of  the  questions),  the 
resulting  data  have  no  dependency  on  specific  questions  (except 
for  provenance  tracking),  so  if  the  form  specification  is  modified, 
then  previous  form  data  are  still  comprehensible  and  sound  (i.e., 
upon  form  specification  changes  the  new  data  and  old  data  remain 
compatible).  However,  if  a  user  requires  data  to  be  structured 
in  a  different  or  more  specialized  format  than  ours,  then  either 
the  software  needs  modifying,  or  a  post-processing  step  would 
be  necessary.  The  value  of  data  in  such  a  structured  format  in 
any  arbitrary  domain  is  twofold:  automating,  or  improving  the 
automation  of  the  process  of  arriving  at  desirable  conclusions 
from  questions  in  the  form,  and  for  further  analysis,  for  instance, 
via  querying.  In  the  clinical  functional  assessment  domain,  our 
modeling  of  forms  and  questions  is  consistent  with  the  format  of 
assessment  instruments  defined  in  LOINC.  However,  the  types  of 
queries  we  formulated  for  functional  assessment  data  are  unfeasible 
using  LOINC,  since  LOINC  provides  no  semantics  behind  what  an 
answer  to  a  specific  question  means. 

We  presented  our  modeling  of  functional  assessments  and 
assessment  instruments,  and  demonstrated  (1)  how  to  generate 
forms  and  acquire  data  based  on  these  OWL  ontologies  and  data 
models,  and  (2)  how  to  make  use  of  the  data  using  queries  on 
individual  subjects  and  queries  that  aggregate  population  data. 


The  modeling  contributions  include  (1)  CFA :  a  clinical  functional 
assessment  domain  ontology  that  allows  defining  questions  being 
asked  in  an  assessment  instrument  in  terms  of  a  rich  ontology  that 
integrates  standard  terminologies  such  as  ICF  and  SNOMED  CT, 
and  which  provides  the  means  for  making  detailed  or  aggregate 
queries  on  acquired  data,  and  (2)  datamodel.  an  information  model 
that  allows  the  specification  of  generic  assessment  forms  and  the 
format  of  structured  data  acquired  through  the  instruments. 

We  have  designed  our  output  model  to  support  the  acquisition 
of  structured  data  through  Web  forms,  and  for  the  potential  to 
integrate  the  data  inside  EHRs.  It  is  straightforward  to  transform 
the  data  we  capture  as  instances  of  Observation ,  Certification , 
Evaluatorlnformation,  and  Subjectlnformation  into,  for  example, 
Health  Level  Seven  (HL7)  Reference  Information  Model  (RIM) 
standard  compliant  data  [5].  Finally,  we  have  shown  that  the 
problem  of  structured  data  acquisition  can  be  suitably  tackled 
using  OWL;  our  solution,  though  applied  to  the  clinical  functional 
assessment  domain  for  the  context  of  this  paper,  is  entirely  generic, 
and  can  easily  be  applied  to  an  arbitrary  domain. 
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ABSTRACT 

Since  its  introduction  in  2001,  the  International  Classification  of  Functioning,  Disability  and  Health  (ICF) 
has  matured  into  a  recognized  standard  for  describing  human  functioning  in  the  context  of  illness.  Many 
have  adopted  instruments  to  help  incorporate  use  of  the  complex  terminology  into  research  and  clinical 
documentation.  Yet  it  remains  unclear  how  this  standard  can  be  best  utilized  in  an  electronic  health  record 
(EHR)  in  order  to  take  advantage  of  the  benefits  such  a  standard  provides,  while  improving  usability  for 
clinicians.  We  developed  a  mechanism  that  uses  ontology-based  Web-forms  to  insulate  the  user  from  the 
details  of  ICF  coding.  The  resulting  form  data  are  linked  to  logical  descriptions  that  use  terms  from  ICF 
and  other  standard  terminologies.  This  solution  allows  us  to  query  and  aggregate  the  resulting  structured 
data  based  on  standardized  descriptions  of  assessment  data  elements,  to  advance  adoption  of  standard 
terminologies  in  clinical  functional  assessment. 

INTRODUCTION 

In  the  spring  of  2001,  the  World  Health  Organization  (WHO)  introduced  the  International  Classification  of 
Functioning,  Disability  and  Health  (ICF)  to  describe  non-fatal  health  outcomes,  and  to  define  functioning 
and  patient  progress  in  rehabilitation,  with  special  attention  to  the  role  of  the  environment  in  human 
functioning  ls  2’ 3.  It  offers  researchers  and  policymakers  a  uniform  standard  language  for  describing  and 
discussing  disability4,  as  well  as  assessing  need  for  services  and  resources5.  The  ICF  consists  of  broad 
multi-dimensional  assessments  using  qualifiers  and  numeric  coding  schemes,  and,  over  time,  many  have 
apportioned  and  focused  the  terminology  to  specific  disciplines  and  fields  to  further  its  utility  in  clinical 
and  research  settings2. 

Despite  its  status  as  the  companion  classification  of  the  International  Classification  of  Diseases  (ICD)  in  the 
WHO’s  Family  of  International  Classifications  (WHO-FIC),  the  adoption  of  ICF  in  clinical  functional 
assessment  is  modest.  In  this  paper,  we  survey  the  literature  to  explore  issues  related  to  the  adoption  and 
uptake  of  ICF,  especially  in  the  context  of  its  usage  to  derive  machine-usable  structured  data.  This  survey 
informs  us  of  the  requirements  that  any  solution  that  advances  the  use  of  standard  terminologies  in  clinical 
functional  assessment  should  meet.  Using  Semantic  Web  technologies,  particularly  the  Web  Ontology 
Language  (OWL),  we  propose  a  new  method  to  incorporate  ICF  in  a  clinical  functional  assessment  (CFA) 
ontology  that  provides  the  basis  for  defining  data  elements  in  structured  assessment  instruments.  Using 
formal  models  of  assessment  forms,  we  developed  a  prototype  application  that  automatically  generates 
Web-based  data-entry  forms.  Through  these  forms,  a  healthcare  provider  can  document  clinical  functional 
assessment  and  generate  EHR-compatible  structured  data  that  can  be  used  for  decision  support  or 
population-based  queries. 

BACKGROUND 

The  WHO  built  the  ICF  as  a  hierarchical  classification  of  1,424  coded  categories  and  1,122  definitions6 
divided  primarily  into  two  parts:  ‘Functioning  and  Disability’,  and  ‘Contextual  Factors’,  and  further 
subdivided  into  four  components:  ‘Body  Functions  and  Structures’,  ‘Activities  and  Participation’, 
‘Environmental  Factors’,  and  ‘Personal  Factors’  (see  Figure  1).  Each  ICF  code  is  assigned  one  or  more 
numeric  qualifiers  to  reflect  the  level  of  facilitation  or  impairment  conferred  by  a  health  condition5. 
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Figure  1.  Hierarchy  of  the  ICF,  depicting  its  major  division  in  two  parts,  and  including  components  and 
qualifiers  (reused  with  permission  from  Kukafka  et  al  2006,  originally  adapted  from  WHO,  2006). 

Clinical  Challenges  to  Use  of  ICF 

Despite  many  advancements  in  incorporating  ICF  into  the  research  and  clinical  realms  lj  2’  6’  7’ 8,  challenges 
remain  in  the  clinical  setting  to  implement  and  utilize  the  ICF  during  patient  visits.  The  broad  scope  of  the 
ICF  is  felt  as  potentially  overwhelming  or  impractical  for  clinicians  to  use  in  a  given  clinical  encounter3,6, 
while  at  the  same  time  lacking  some  codes  that  were  sufficiently  unique  or  detailed3,9.  Critics  pointed  to 
lack  of  guidance  on  clinical  implementation,  resulting  in  uneven  and  idiosyncratic  implementation3, 8,  and 
others  cited  lack  of  empirical  evidence  of  clinical  utility  and  questioned  whether  the  complex 
implementation  of  ICF  had  any  benefit  for  patients  at  all8.  Anner  et  al  felt  that  the  application  of  ICF  to 
describe  work  disability  was  limited  since  it  does  not  include  key  features  of  the  disability  evaluation,  such 
as  the  dynamic  time  perspective  or  the  restricted  causal  connection  between  functional  capacity  and  the 
health  condition6.  Perhaps  as  a  result,  ICF  coding  has  achieved  limited  integration  into  clinical 
documentation  in  physiotherapy10.  This  suggests  that  ICF  needs  to  be  complemented  with  other  standard 
terminologies,  and  appropriate  uses  of  the  terminology  should  be  predefined  so  that  they  are  implemented 
correctly,  yet  details  are  hidden  from  the  user. 


Outcomes  Research  and  Linking  Rules 

“Linking  Rules”  were  soon  developed  and  refined  to  promote  the  application  of  ICF  as  a  connecting 
framework  between  interventions  and  outcome  measures,  and  to  allow  researchers  to  systematically  link 
and  compare  meaningful  concepts  contained  in  different  health-status  measures,  technical  and  clinical 
measures,  and  interventions11.  The  use  of  ICF  as  a  reference  standard  for  patient-oriented  outcome 
measures  is  practical  when  such  a  standardized  procedure  enables  interventions  and  outcome  measures  to 
be  linked  to  the  ICF  terminology4.  Several  authors  have  found  that  linking  rules  have  practical  value  in 
clinical  settings3,12,13,14. 

The  Electronic  Health  Record  (EHR) 

Incorporating  physiotherapy  functional  assessment  in  a  coded  format  into  electronic  health  records  can  help 
to  leverage  features  that  are  valuable  for  health  information  exchange,  clinical  decision  support,  and  can 
potentially  improve  patient  care  outcomes10.  Vreeman  and  Richoz  describe  how  the  ICF  could  advance 
clinical  practice  and  research  by  enabling  data  sharing  and  reuse  by  EHRs10.  However,  incorporating  coded 
functional  assessment  into  an  EHR  faces  some  hindrances.  Beyond  ICF,  there  are  several  alternative 
standards  and  assessments  available  to  clinicians,  for  example:  Discipline-specific,  SNOMED,  LOINC,  etc. 


Documentation  formats  range  from  paper  notes,  free  text  entry,  and  structured  data  entry,  all  of  which  raise 
unique  challenges  for  clinicians  and  computers  regarding  how  the  data  is  recorded  and  analyzed.  Any 
solution  to  EHR  incorporation  of  ICF-based  assessments  should  address  the  variety  of  standards  and 
assessment  instruments,  and  take  into  account  the  preferred  documentation  format. 

Structured  Data  Entry 

Since  unstructured  ‘free  text’  narrative,  commonly  seen  in  rehabilitation  assessment  notes,  is  not  easily 
utilized  by  software,  some  have  advocated  Natural  Language  Processing  (NLP)  approaches  to  improving 
coding  of  ICF  with  assessment  data  entry.  Kukafka  and  her  colleagues  advocate  the  practicality  of  the 
automated  Medical  Language  Extraction  and  Encoding  system  (MedLEE)  NLP  system,  which  selects  ICF 
codes  and  performance  qualifiers  better  than  non-expert  human  coders,  though  not  as  well  as  expert  human 
coders.  They  found  that  the  NLP  system  produced  levels  of  agreement  on  code  assignments  that  were 
generally  higher  for  the  first  qualifier  (performance)  and  lower  for  the  second  qualifier  (capacity). 

However,  coding  tasks  involving  complex  reasoning  (i.e.,  requiring  assimilation  of  multiple  sources  and 
types  of  information  as  might  be  required  in  a  disability  assessment)  remain  a  difficult  challenge  for  current 
NLP  systems5. 

Because  of  these  difficulties  with  NLP  systems,  others  have  advocated  the  advantages  of  structured  data 
entry.  Structured  data  entry  offers  a  viable  pathway  in  implementing  and  using  ICF  within  the  EHR. 
Vreeman  and  Richoz  propose  template-based  data  entry  to  facilitate  data  collection  and  analysis  by 
computer,  framed  by  ICF  standards10.  They  describe  the  incorporation  of  ICF  coding  into  an  EHR,  yielding 
specific  clinical  reminders  for  providers  to  address,  as  well  as  enhancing  abilities  to  generate  reports, 
calculate  function  scores,  and  enhance  clinical  decision  making.  While  many  clinicians  balk  at  structured 
data  entry  in  the  clinical  encounter  and  can  find  coding  terminology  distracting  from  the  flow  of  patient 
records,  Vreeman  and  Richoz  suggest  that  the  identifiers  (codes)  and  names  from  the  vocabulary  can  be 
hidden  inside  the  EHR  while  the  clinician  interacts  with  customary  concept  labels10.  They  call  for 
additional  work  to  define  the  relationships  between  assessment  instruments,  ICF  and  other  vocabulary 
standards  in  a  computer-interpretable  way10. 

In  recent  years,  LOINC  has  been  extended  to  capture  data  elements  in  assessment  instruments15.  LOINC 
allows  the  aggregation  of  assessment  items  into  a  hierarchy  of  panels.  For  each  assessment  item,  LOINC 
maintains  attributes  such  as  ‘Question  Text’,  ‘Question  Source’,  data  type  of  answers,  and  structured 
answer  lists.  Much  of  our  representation  of  assessment  forms,  questions,  and  answers  parallel  LOINC’s 
organization.  LOINC,  however,  does  not  attempt  to  model  the  questions  and  answers  in  assessment 
instruments  semantically  in  terms  of  ontologies  relevant  to  functional  assessments.  Each  LOINC 
assessment  item  stands  alone.  For  example,  a  visual  assessment  item  for  “near  acuity”  has  no  relationship 
to  another  item  “far  acuity”.  Because  these  two  assessment  items  are  not  logically  related  (in  a  hierarchy), 
one  cannot  use  automated  reasoning  to  infer  that  a  subject  has  a  generalized  visual  acuity  problem  based  on 
responses  to  the  two  assessment  items. 

METHODS 

Given  the  requirements  we  have  outlined  in  the  previous  section,  we  focus  on  developing  methods  to 
acquire  EHR-compatible  structured  data  through  assessment  forms.  Additionally,  we  explore  the  use  of 
Semantic  Web  technologies  to  develop  new  types  of  linking  rules  for  systematically  linking  and  comparing 
meaningful  concepts  contained  in  different  health-status  measures,  technical  and  clinical  measures,  and 
interventions.  Our  modeling  of  components  of  assessment  forms  is  similar  to  LOINC’s  approach,  including 
the  division  into  sections  and  questions,  and  the  definition  of  possible  answers  to  the  questions.  However, 
our  work  extends  the  LOINC  representation  by  modeling  the  semantic  content  of  the  questions  by  giving 
these  questions  formal  definitions  in  terms  of  a  Clinical  Functional  Assessment  (CFA)  ontology, 
represented  in  OWL.  The  CFA  ontology  provides  concepts  and  relationships  that  allow  us  to  give  formal 
descriptions  of  the  findings,  assessments,  and  measurements  embodied  in  the  assessment  instruments.  From 
the  model  of  assessment  instruments,  we  generate  Web-based  data-acquisition  forms,  through  which 
clinicians  can  easily  document  necessary  assessments.  The  backend  of  our  tool  automatically  generates 
structured  data  in  multiple  formats.  The  data  can  be  post-processed  into  formats  consistent  with  those  of 
Health  Level  7  via  simple  transformations,  and  made  available  for  querying  and  aggregation. 


Clinicians  use  the  “Back  (Thoracolumbar  Spine)  Conditions”  Disability  Benefits  Questionnaire  (DBQ)  to 
assess  veteran’s  musculoskeletal  disability.  We  use  this  DBQ  as  one  of  our  exemplar  assessment 
instruments  (see  Figure  2)  with  the  objective  of  capturing,  as  structured  data,  answers  documented  by  these 
clinicians.  We  will  illustrate  the  use  of  the  CFA  ontology  to  structure  the  information  about  the  severity  of 
constant  pain  caused  by  radiculopathy  of  the  left  lower  extremity. 


_ SECTION  XII  ■  RADICULOPATHY _ 

12A.  DOES  THE  VETERAN  HAVE  RADICULAR  PAIN  OR  ANY  OTHER  SIGNS  OR  SYMPTOMS  DUE  TO  RADICULOPATHY? 

□  YES  □  NO  IF  YES,  COMPLETE  THE  FOLLOWING  SECTION: 

12B.  INDICATE  SYMPTOMS’  LOCATION  AND  SEVERITY  (check  all  that  apply): 

Constant  pain  (may  be  excruciating  at  times) 

Right  lower  extremity:  Q  None  Q  Mild  Q  Moderate  Q  Severe 
Left  lower  extremity:  None  Mild  Moderate  ~\  Severe 

Figure  2.  A  fragment  of  the  “Back  (Thoracolumbar  Spine)  Conditions”  Disability  Benefits  Questionnaire. 

It  shows  the  dependency  of  questions  (question  12B  needs  to  be  completed  only  if  the  answer  to  question  to 
12A  is  “YES”)  and  how  a  question  (e.g.,  12B)  is  subdivided  into  subquestions  (severity  of  pain  in  either 
lower  extremity). 

The  CFA  ontology  is  divided  into  three  main  branches:  (1)  DataElementDescription  that  defines  a  Finding 
(the  result  of  an  observation,  measurement,  or  judgment,  (2)  ValueSet  that  defines  collections  of  possible 
qualifiers  and  values  for  findings,  and  (3)  SubjectMatterOntology  that  provides  internally  defined  domain 
concepts  that  either  are  not  available  in  standard  terminologies  or  are  references  to  standard  terms  that  need 
to  be  organized  into  taxonomies.  The  Finding  class  is  further  subdivided  into  Assessment  (those  findings 
that  have  non-numeric  results)  and  Measurement  (those  findings  that  have  numeric  results).  We  also  define 
FunctionalAssessment  (a  subclass  of  Assessment).  In  general,  a  functional  assessment  will  have  some 
assessed  function  that  can  be  related  to  an  ICF  body  function  or  activity  (possibly  as  an  exact  match, 
specialization,  or  generalization),  some  assessed  attribute,  such  as  severity,  that  specifies  the  dimension  of 
the  function  being  assessed,  and,  optionally,  some  anatomical  location  of  the  assessment.  Findings  and 
functions  can  be  modified  by  qualifiers  that  further  refine  these  entities.  For  example,  a  functional 
assessment  may  be  made  in  the  context  of  using  assistive  devices,  and  a  function  being  assessed  may  have 
some  temporal  component  (e.g.,  constant  pain).  CFA  imports  a  version  of  ICF  that  is  represented  in  OWL. 
Thus,  all  ICF  categories,  such  as  ‘body  structure’,  ‘body  function’,  ‘activities  and  participation’,  and 
‘environmental  factors’  are  available  for  formalizing  descriptions  of  functional  assessments.  For  other 
standard  terminologies  such  as  SNOMED  CT,  ICD,  and  LOINC,  instead  of  importing  them  as  ontologies, 
we  make  references  to  them  through  instances  of  Externally  Co  dedValue. 

Figure  3  shows  how  the  assessment  of  constant  pain  caused  by  radiculopathy  in  the  left  lower  extremity  is 
modeled.  To  make  it  easier  for  descriptions  of  questions  and  answers  in  a  form  to  reference  this  class,  we 
create  an  individual  that  is  the  “prototypical  instance”  of  the  class  (as  shown  in  ). 

cfa:hasAnatomicalLocation  some 

(‘icf:s750.  Structure  of  lower  extremity' 
and  (cfa:hasLaterality  value  cfa:Left)> 

cfa:hasAssessedFunction  some 
(cfa:Function 

ant  (cfa:isExactMatchOf  some  *icf:b2801.  Pain  in  body  part') 
an<  (cfa:causedBy  value  cfa:Radiculopathy) 
and  <cfa:hasQualifier  value  cfa:Constant)) 

# cfa:measuredOrAssessedAttribute  value  cfa:severity 

Figure  3.  Definition  of  constant  pain  caused  by  radiculopathy  on  the  lower  left  extremity.  It  shows  that  the 
finding  is  defined  in  terms  of  the  function  being  assessed,  the  assessed  attribute  of  the  function,  and  the 


anatomical  location  of  the  assessment.  In  each  case,  the  value  of  the  property  can  be  constrained  by 
expressions  that  reference  internally  defined  value  sets  or  terms  from  external  terminologies. 

Besides  the  CFA  ontology,  we  have  also  created  a  datamodel  ontology,  which  provides  a  generic,  context- 
free  representation  of  a  form  (e.g.,  it  models  elements  such  as  questions  and  sections)  and  the  data 
generated  from  a  form  (e.g.,  a  string  value  from  a  text  area,  or  values  from  an  enumerated  value  set).  Figure 
4  summarizes  key  aspects  of  our  modeling:  elements  of  a  form  are  asserted  as  subclasses  of  FormStructure , 
such  as  Form ,  Section  and  Question.  Each  kind  of  FormStructure  generates  some  kind  of  Data ;  every  form 
submission  generates  an  instance  of  FormData ,  which  references  (via  the  hasComponent  property)  all 
instances  of  Data  generated  in  the  process  of  parsing  form  answers.  Specific  sections  such  as 
SubjectlnfoSection  collect  information  pertaining  to  a  subject,  and  these  details  are  aggregated  in  an 
instance  of  Subjectlnformation.  An  answer  to  an  instance  of  Question  gives  rise  to  an  instance  of 
Observation  with  a  has  Value  property  assertion  to  the  IRI  of  the  selected  answer.  An  instance  of 
Observation  will  be  inferred  to  have  an  outgoing  hasFocus  property  assertion  if  the  question  it  derives  from 
encodes  some  kind  of  semantic  description  of  the  question’s  meaning.  Figure  5.  shows  the  modeling  of  a 
question  about  constant  pain  caused  by  radiculopathy  of  the  lower  left  extremity. 


cfa :  isComponentOf 


hasOuestion  cfa :  isComponentOf 


cfa  :  isAbout 


cfa  :  hasFocus  cfa  :  has  Value 


DataElementDescription 


DataElementValue 


Figure  4.  Excerpt  of  the  datamodel  ontology  classes  and  relations.  The  left-hand  side  of  the  figure  shows 
the  components  of  a  form  and  how  a  question’s  semantic  content  (the  value  of  the  cfa \is About  property)  is 
defined  by  concepts  in  the  CFA  ontology.  The  right-hand  side  of  the  figure  shows  the  structure  of  the  data 
generated  from  answers  to  these  questions. 


Description:  dbq:DBQ_Back_Q12B_l_2  HB1B 


Property  assertions:  dbq:DBQ_Back_Q12B_l_2  [EBBE 


Types  Q 

•  cfaihasValue  some 

({cfa:Mild  ,  cfa: Moderate  , 
cfa:  None  ,  cfa:Severe>) 

i  datamodehQuestion 


oooo 

0060 


Same  Individual  As 


O 


Object  property  assertions 

l  cfa:isAbout  oooo 

cfa:constant  pain  left  lower  ex 

Data  property  assertions 

•  cfa:hasText  "Left  lower  oooo 

extremity  :"AAxsd:string 


Figure  5.  Modeling  of  a  question  about  constant  pain  caused  by  radiculopathy  of  the  lower  left  extremity. 
The  cfa:isAbout  property  references  an  individual  (< constant _pain_left_lower_extremity )  in  the  CFA 
ontology  that  is  the  prototypical  instance  of  a  class  of  the  same  name.  The  cfa:hasText  property  specifies 
the  string  that  should  be  displayed  with  the  question,  and  the  cfa:hasValue  property  is  constrained  by  the 
value  set  for  answers  to  this  question. 


Based  on  the  modeling  of  forms  and  questions,  we  developed  a  Java-based  application  that  generates  a 
Web  form  that  a  healthcare  provider  can  use  to  enter  assessments  that  are  captured  as  structured  data  by  the 
backend  (see  Figure  6).  The  application  takes  as  input  a  specification  of  a  form  (such  as  the  ‘Back’  DBQ 
form)  in  an  ontology,  and  a  user  defined  configuration  file. 


O  RADICULOPATHY 


A)  DOES  THE  VETERAN  HAVE  RADICULAR  PAIN  OR  ANY  OTHER  SIGNS  OR  SYMPTOMS  DUE  TO  RADICULOPATHY?  (IF  YES,  COMPLETE  THE 
QUESTIONS  BELOW) 

OYes  ONo 


A1)  INDICATE  SYMPTOMS'  LOCATION  AND  SEVERITY  (check  all  that  apply): 


Constant  pain  (may  be  excruciating  at  times) 


Right  lower  extremity: 

□  None  □  Mild  □  Moderate  □  Severe 


Left  lower  extremity: 

□  None  □  Mild  O  Moderate  O  Severe 

Figure  6.  DBQ  questions  concerning  the  symptoms  of  radiculopathy.  The  form  was  generated  from  a 
specification  of  the  questions  on  the  “Back  (Thoracolumbar  Spine)  Conditions”  DBQ.  After  a  healthcare 
provider  submits  assessment  data  using  this  form,  the  system  generates  structured  data  using  the  form 
specification,  the  output  data  model,  and  concepts  from  the  CFA  ontology. 

RESULTS 

We  have  developed  a  proof-of-concept  system  that  includes  complete  modeling  of  two  DBQs.  One  of  the 
authors  (MJT),  who  is  a  physician  from  the  VA  Palo  Alto  Healthcare  System,  reviewed  and  validated  the 
generated  Web  forms,  and  created  data  for  a  number  of  simulated  patient  cases.  The  data  generated  can  be 
saved  as  tab-delimited  files  or  Semantic  Web  documents  (RDF  or  OWL).  While  the  data  can  be 
transformed  into  formats  consistent  with  those  of  HL7  data  format,  we  stored  our  gathered  data  in  a  graph 
database  with  support  for  SPARQL  1.1  querying  and  OWL  2  reasoning. 

The  data  captured  through  our  Web  forms  is  both  structured  and  semantically  enriched  because  it  is  linked 
to  the  CFA  ontology’s  modeling  of  data  elements.  We  create  a  link  by  asserting  a  question’s  semantic 
description,  encoded  as  an  isAbout  relation,  into  the  hasFocus  property  of  the  data  derived  from  that 
question.  For  example,  the  back  DBQ  has  a  question  about  the  severity  of  constant  pain  caused  by 
radiculopathy  of  the  left  lower  extremity.  An  observation  derived  from  this  question  will  have  a  focus  that 
is  a  reference  to  the  class  defined  by  the  expression  shown  in  ,  and  some  value,  for  instance,  4  severe ’.This 


kind  of  semantic  modeling  allows  us  to  query  and  aggregate  the  data  along  the  dimensions  that  define  a 
clinical  functional  assessment  (e.g.,  severity,  assessed  function,  and  anatomical  location).  Figure  7  shows 
an  OWL  query  that  retrieves  all  observations  of  severe  pain  anywhere  in  the  lower  extremity.  It  is  worth 
observing  that  this  query  is  formulated  in  such  a  way  that  it  is  independent  of  the  assessment  instrument, 
including  the  formulation  of  the  question.  Instead,  the  query  is  formulated  in  terms  of  entities  defined  in  our 
CFA  ontology. 

datamodel :Observation  and 
cfa:hasvalue  value  cfa:severe  and 
cfa:hasFocus  some  (cfa: Assessment  and 

(cfa: hasAssessedFunction  some(cfa: i sExactMatchOf  some  icf:b2801))  and 
(cfa :hasAnatomi cal  Location  some  icf:s750)) 

Figure  7.  OWL  query  for  retrieving  all  observations  of  severe  pain  in  the  lower  extremity. 

DISCUSSION 

We  have  demonstrated  a  method  to  bridge  the  gap  between  assessment  instruments  commonly  used  to 
perform  clinical  functional  assessment  and  standard  terminologies  such  as  ICF.  Our  CFA  ontology  allows 
us  to  define  questions  in  assessment  instruments  in  terms  of  concepts  and  relationships  specified  in  the 
ontology.  These  formal  descriptions,  in  turn,  reference  terms  from  standard  terminologies  such  as  ICF  and 
SNOMED  CT.  The  descriptors  of  functional  assessment — the  function  and  its  attribute  being  assessed, 
possible  anatomical  locations,  and  qualifiers  on  assessments  and  functions — are  parallel  to  the  categories 
and  qualifiers  of  ICF.  However,  the  value  sets  for  these  descriptors  do  not  have  to  be  limited  to  ICF,  and 
can  use  terms  from  other  standard  terminologies.  Furthermore,  the  ontology  provides  the  flexibility  of 
linking  functional  assessment  concepts  with  other  clinical  entities.  For  example,  in  our  example  of  pain 
caused  by  radiculopathy,  we  used  the  caused  by  property  to  link  the  pain  being  assessed  to  the  SNOMED 
CT  concept  for  radiculopathy.  Users  of  the  assessment  instruments  do  not  have  to  understand  the  complex 
ICF  coding  scheme  and  its  extensions.  The  system  automatically  generates  structured  data  consistent  with 
the  use  of  ICF. 

The  CFA  ontology  plays  a  role  similar  to  that  of  “Linking  Rules”  described  in  the  Background  section.  It 
provides  a  logic-based  connecting  framework  for  comparing  and  harmonizing  intervention  and  outcome 
measures  from  different  instruments.  Because  of  the  amount  of  work  needed  to  build  consensus  and  to 
formally  describe  the  needed  functional  assessments,  organizations  that  develop  discipline-specific 
assessment  instruments  need  to  take  the  lead  to  define  appropriate  components  of  the  CFA  ontology. 

Our  prototype  implementation  of  the  form-based  assessment  instruments  have  some  standard  features  that 
help  to  save  time  for  healthcare  providers,  such  as  automated  population  of  sub-questions  if  a  top-level 
question  has  a  certain  value  (e.g.,  “all  normal”).  Nevertheless  an  experienced  clinician  no  doubt  can 
document  functional  assessment  more  rapidly  using  a  paper  form.  The  benefit  of  using  an  instrument  like 
ours  is  the  possibility  of  automatically  generating  structured  data  that  can  be  queried,  aggregated,  and 
transformed  into  standard  formats,  thus  bringing  clinical  functional  assessment  one  step  closer  to  being 
integrated  with  a  modem  EHR. 

CONCLUSION 

The  adoption  of  ICF  has  been  hindered  by  a  stmcture  that  coders  and  clinicians  find  difficult  to  use. 
Ontology-based  forms  for  stmctured  data  entry  can  offer  a  bridge  from  the  clinical  encounter  to 
computerized  data  analysis.  Ideal  solutions  should  mesh  well  with  clinical  workflow  and  enable  data 
recording  by  clinicians  and  researchers  in  a  logical  and  rapid  fashion.  Such  technical  solutions  should 
likewise  be  configurable  to  different  terminologies  to  address  the  needs  of  clinicians  and  researchers. 
Stmctured  data  entry  is  a  recognized,  though  imperfect,  format  for  recording  data  in  the  clinical  encounter, 
and  has  back-end  advantages  over  NLP  systems.  We  have  built  on  existing  terminologies  and  reuse  their 
terms  to  constmct  an  ontology  of  functional  assessment.  This  ontology  overcomes  significant  limitations  of 
the  native  ICF  coding  stmcture. 

We  developed  a  mechanism  that  employs  non-obtmsive  ontology-based  Web-forms  to  encode  key 
functional  assessment  data,  using  terms  from  ICF  and  other  standard  terminologies.  This  solution  allows  us 


to  query  and  aggregate  the  resulting  structured  data,  based  on  standardized  descriptions  of  assessment  data 
elements.  Our  solution  can  advance  adoption  of  standard  terminologies,  facilitate  health  information 
exchange  and  clinical  decision  support,  and  bring  to  bear  the  full  power  of  modem  electronic  health 
records. 
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